Good point.
Actually, I'm wondering whether this will be sufficient.
Perhaps a safer approach is that we define a schema-drop-source property
(that looks exactly like schema-generation-source, with the same defaults)
to cover this.
What do you all think?
-Linda
On 1/31/2013 11:13 AM, Steve Ebersole wrote:
> 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
>>>
>>>
>>>
>>>
>>
>