I guess what I was getting at yesterday is that it *seems* as if the
intent is that 'javax.persistence.ddl-create-script-target' and
'javax.persistence.ddl-drop-script-target':
1) need to be specified either both together or neither
2) Control:
2.a) whether scripts are generated
2.b) what types of scripts are generated.
So if I have:
javax.persistence.schema-generation-action=create
javax.persistence.schema-generation-target=database-and-scripts
javax.persistence.ddl-create-script-target=<something>
javax.persistence.ddl-drop-script-target=<something>
the "action=create" bit really only describes the database target side
of things. On the script target side, both create and drop are created.
To me at least that is not the most intuitive set up. If I say
"action=create", why are the drop scripts being generated?
On Thu 31 Jan 2013 03:03:43 PM CST, Steve Ebersole wrote:
> Well the confusion IMO as a user is that I specifically asked for only
> creation scripts to be generated, but got both creation and drop
> scripts. Thats not going to change by making schema-generation-target
> required. Even this is still confusing:
>
> javax.persistence.schema-generation-action=create
> javax.persistence.schema-generation-target=scripts
> javax.persistence.ddl-create-script-target=<something>
> javax.persistence.ddl-drop-script-target=<something>
>
>
> because i would not expect to get a drop script. But if I read the
> other parts of the spec correctly, the following actually results in
> an exception:
>
> javax.persistence.schema-generation-action=create
> javax.persistence.schema-generation-target=scripts
> javax.persistence.ddl-create-script-target=<something>
>
> The exception is because 'javax.persistence.ddl-drop-script-target' is
> not specified, again even though i just said I only want create
> scripts generated.
>
> On Thu 31 Jan 2013 02:13:20 PM CST, Linda DeMichiel wrote:
>>
>>
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>