jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: schema generation open issues

From: Steve Ebersole <steve.ebersole_at_redhat.com>
Date: Sat, 02 Feb 2013 10:13:26 -0600

WRT various source scripts (DDL create/drop sources, import script
sources) what are we saying is the standard for delimiters? Or is this
up to each provider?

In Hibernate we actually hide this behind an interface so that it is
pluggable. The interface, as you would imagine, is very simple. Is
that something we want to explore for the spec?

public interface ImportSqlCommandExtractor {
     public String[] extractCommands(Reader reader);
}


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
>
>
>
>