users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: schema generation open issues

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Thu, 31 Jan 2013 12:13:20 -0800

On 1/31/2013 11:52 AM, Steve Ebersole wrote:
> I also am not sure about this passage in discussing 'javax.persistence.ddl-create-script-target' and
> 'javax.persistence.ddl-drop-script-target':
>
> <quote>
> The persistence provider must produce both create and drop scripts if the corresponding
> DDL targets are specified. This is independent of whether a drop action is included in the
> value passed for the javax.persistence.schema-generation-action property.
> </quote>
>
> To me, this sounds like you are saying that the following config will generate both create and drop scripts:
>
> javax.persistence.schema-generation-action=create
> javax.persistence.ddl-create-script-target=<something>
> javax.persistence.ddl-drop-script-target=<something>
>
> even though the config explicitly specified just create scripts. Is that your intent?
>

yes

> Same for:
>
> javax.persistence.schema-generation-action=drop
> javax.persistence.ddl-create-script-target=<something>
> javax.persistence.ddl-drop-script-target=<something>
>
> that is supposed to generate both create and drop scripts?
>

yes

>
> Perhaps the reasoning is that javax.persistence.schema-generation-action is really just geared towards
> javax.persistence.schema-generation-action=database.

partially. also it was intended to control whether any action would be taken.

I'm thinking that all this might be clearer if we required schema-generation-target to be specified.

But if that is the case, maybe we ought to rename the setting to be
> more explicit of that fact or at least document it in the discussion of 'javax.persistence.schema-generation-action'
>
>
> On 01/31/2013 01:13 PM, 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>