On 1/31/2013 11:52 AM, Steve Ebersole wrote:
I also am not sure about this passage in discussing
The persistence provider must produce both create and drop scripts if
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
To me, this sounds like you are saying that the following config will
generate both create and drop scripts:
even though the config explicitly specified just create scripts. Is
that your intent?
that is supposed to generate both create and drop scripts?
Perhaps the reasoning is that
javax.persistence.schema-generation-action is really just geared towards
partially. also it was intended to control whether any action would
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
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 22.214.171.124 ("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
Please review these sections and post any feedback. Changes are
This section isn't sufficiently clear about requirements for the
specification of schema-generation-action and
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
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
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
flexible, and that we should support a combination of ORM and script
sources. (For example, consider the case where generation should
from scripts, but it is desirable to add stored procedures to the
I therefore propose that we add a schema-generation-source property
that will support such combination. Again, if script sources are
by the properties for scripts, then generation will default to use of
only script sources; if script sources aren't specified, then
will default from the ORM metadata.
I've also received feedback (from our JPA/EE integration engineer)
we need to specify that in Java EE environments that strings
to file URLs must use absolute (and not relative) paths. I've
clarification as well.
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
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 126.96.36.199. If you disagree, please speak up.
[jpa-spec users] [jsr338-experts] Re: schema generation open issues