One quick question.
For 'javax.persistence.schema-generation-source' values of
metadata-then-scripts and scripts-then-metadata is the order the same
for both create and drop?
I can envision a situation, for example, with metadata-then-scripts
where the metadata creates a table and then the script creates a
procedure. I am not sure that all databases will allow you to drop the
table if other database objects refer to it. Would it be better to say
that the defined order (x-then-y) applies to create, but the reverse
order (y-then-x) applies to drop?
On 01/31/2013 12:49 PM, Steve Ebersole wrote:
> These look great. Thanks Linda.
>
> On 01/28/2013 05:14 PM, Linda DeMichiel wrote:
>> There are currently a few open issues in schema generation that need
>> clarification. These pertain to sections 9.4 ("Schema generation")
>> and 8.2.1.9 ("properties") in the spec.
>>
>> I've made some clarifications and proposed some additions to the
>> metadata for schema generation as described below. The draft I've
>> just uploaded reflects these changes
>> (http://java.net/projects/jpa-spec/downloads/download/JavaPersistence01282013.pdf).
>> Please review these sections and post any feedback. Changes are
>> summarized below.
>>
>> ----
>>
>> Section 9.4
>>
>> This section isn't sufficiently clear about requirements for the
>> specification of schema-generation-action and schema-generation-target.
>>
>> I've clarified that schema-generation-action must be specified or no
>> actions will be taken. This was an assumed default in the current
>> public draft, but IMO not sufficiently explicit.
>>
>> Given the clarification to schema-generation-action, I think it now
>> makes sense for schema-generation-target to have default values.
>> That is, if script targets are specified by the properties for scripts,
>> then generation actions should default into scripts. If not, actions
>> should be directly into the database.
>>
>> The current public draft assumes that if script sources are specified,
>> generation should occur from scripts exclusively; and conversely, if
>> script sources are not specified, generation should occur exclusively
>> from the ORM metadata. I've gotten feedback that this wasn't
>> sufficiently
>> flexible, and that we should support a combination of ORM and script
>> sources. (For example, consider the case where generation should occur
>> from scripts, but it is desirable to add stored procedures to the
>> database.)
>> I therefore propose that we add a schema-generation-source property
>> that will support such combination. Again, if script sources are
>> specified
>> by the properties for scripts, then generation will default to use of
>> only script sources; if script sources aren't specified, then generation
>> will default from the ORM metadata.
>>
>> I've also received feedback (from our JPA/EE integration engineer) that
>> we need to specify that in Java EE environments that strings
>> corresponding
>> to file URLs must use absolute (and not relative) paths. I've added
>> that
>> clarification as well.
>>
>>
>> Section 8.2.1.9
>>
>> In the current public draft, this section lacks information as to how
>> script locations are specified. I've added a clarification that
>> scripts packaged as part of the application must be specified relative
>> to the root of the persistence unit, as we do for other packaged
>> artifacts. I've also added a clarification about the expectations for
>> use of file URLs in Java EE environments as above.
>>
>> Finally, when I wrote this up initially, I was reluctant to add
>> metadata for schema generation actions (including targets) because I
>> believed that such metadata should not be specific to the persistence
>> unit definition itself. It seems however that people expect that the
>> use of these properties (as specified in section 9.4) will be
>> available anyway, whether they are specified in the spec document or
>> not, and that some vendors will support these anyway as well.
>> Further, this additional metadata may facilitate ease of use in
>> prototyping/development environments. I've therefore added these
>> properties into 8.2.1.9. If you disagree, please speak up.
>>
>>
>> thanks,
>>
>> -Linda
>>
>>
>>
>>
>