jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: Schema generation feedback

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Mon, 07 Jan 2013 15:47:30 -0800

Hi Emmanuel,

Thanks for the feedback. Some comments and further questions for you and the group below....

-Linda


On 1/2/2013 7:51 AM, Emmanuel Bernard wrote:
> Hello everyone and happy new year to all,
>
> I have been discussing the schema generation feature with Max in our
> tooling team. We have some minor feedback
>
> We probably should offer a default value for create-script-target / drop-script-target.

What did you have in mind here?

> Also being able to specify relative paths would be useful to not have to
> change these from one environment to another.
>
> What kind of URLs are accepted for destinations? Only file based URLs or
> any thing? Not sure we want to be forced to write support for every URL
> protocol on the planet.
>

I'm assuming we should support file-based URLs. I'd like to hear from the group as
to what other protocols should be supported.

> Does create-database-schemas also cover the (non) creation of catalogs
> for completeness (CREATE CATALOG command)?
>

If catalog is functionally equivalent to schema, then yes. If catalog
were functionally equivalent to database, then I would say not.
What do you think?


> Is the *-script-source considered mutual exclusive from the generated script
> execution or is it considered something that is run in *addition* to these scripts ?
>

I'm not sure I'm understanding the question, but I'll give it a try :-) ...

The way the schema generation section is currently written (although perhaps not
explicitly enough), it is assumed that schema-generation-target and
schema-generation-action must be specified. *-script-source wouldn't be
mutually exclusive then, but rather complementary.
So, does your question then reduce to whether specification of the *-script-source
properties, by themselves, should be sufficient to cause tables to be created, dropped, or
both?

> Should generateSchema be renamed prepareSchema to better reflect what
> actually happens? It's not necessary just schema generation but can
> involve creation / update / drop etc.
>

I'm generally not too wedded to particular names, but "schema generation" as a
generic term seems to have become fairly established. If we were to change it
though, what did you have in mind for the related property names?


> Emmanuel