Skip to main content

[jsr338-experts] Re: JPA schema generation

  • From: Steve Ebersole <steve.ebersole@...>
  • To: Linda DeMichiel <linda.demichiel@...>
  • Cc: jsr338-experts@...
  • Subject: [jsr338-experts] Re: JPA schema generation
  • Date: Tue, 15 May 2012 13:56:56 -0500

I tried to point some of them out on the other thread(s), but they were not well received. I think we are missing consolidated annotations for (1) naming/defining the "tenant discriminator column" and (2) an annotation to identify entities that are "shared data" (non tenant aware). As is, every vendor is going to have to create custom versions of these annotations (or not be flexible in terms of user needs). I think it would be better done up front to avoid fragmentation out of the gate. And neither of them are necessarily even PaaS versus SaaS specific.

Anyway, I will certainly look over the proposal more this evening and respond.


On Tue 15 May 2012 01:43:24 PM CDT, Linda DeMichiel wrote:


On 5/15/2012 11:35 AM, Steve Ebersole wrote:
Well part of the problem is that JPA decided to go a totally
different implementation direction for multi-tenancy
support than what I did for Hibernate. It takes a fair amount of
extrapolation based on my work and experiences there to
bear relevant discussion on this JPA approach.


We will need to make sure that we will be able to accommodate both
container-managed
SaaS multitenancy (with stiping) as well as application-managed SaaS
in the future, so
your experience here is very valuable. If you could flag anything that
might stand in
the way of that, it would be very helpful.

regards,

-Linda

But I will read through your proposal some more this evening and
respond back.

On Tue 15 May 2012 01:17:19 PM CDT, Linda DeMichiel wrote:


On 5/15/2012 11:09 AM, Steve Ebersole wrote:
Is the hope to have schema generation supported with multi-tenancy?

Yes -- all the pieces need to fit together.

I see no why for the JPA provider to know whether
the schema needs to be generated because of this segmentation where
an EMF only serves a single tenant. So is the plan
there to put the onus to keep track of that on the environment? You
seem to prefer the environment to manage the schema
generation (the JPA provider simply generates a generation script as
I read your proposal), so maybe this is not so bad.


I've also proposed that when the JPA provider "owns" the database
(i.e., the database
is a dedicated rather than a shared database) that the JPA provider
creates the schemas
in the database. The process as a whole, however, is driven from the
platform provider side.

I would really like to get feedback from you and the other experts in
the group on the details
here. The hard part is always in the details :-)

thanks again,

-Linda

As for know if dropping is necessary, heck put all the onus on the
environment ;)


On Tue 15 May 2012 12:57:15 PM CDT, Linda DeMichiel wrote:
Folks,

I'd like to get more feedback on this.

thanks,

-Linda


On 5/9/2012 11:36 AM, Linda DeMichiel wrote:

In conjunction with support for use of JPA in PaaS environments, we
will need to address the issue of schema generation. After we
discuss
this area, I'd like to return to a broader discussion of
multitenancy
support with this in view.


Here's what I think we'll need to address:

1. How/when schema generation happens:
a. at a deployment time phase (or predeployment time phase)
b. at EMF creation time

2. Providing an option whereby the application can supply DDL for
schema generation as an alternative to the persistence provider
doing schema generation based on the ORM metadata

3. How, once schema generation has happened, tables can get loaded
with
data. If we enable the application to provide DDL scripts for
schema generation, then supporting the use of SQL bulk insert
scripts
would go hand-in-hand with this, but perhaps there are also other
approaches, e.g., bulk insert via JPQL(?).

4. The need for additional ORM metadata: e.g. metadata for index
generation; for foreign key constraints; other(?).

5. More precise definition of existing metadata that can be used
for schema generation: what it comprises, and how it can/must
be used.

6. Additional persistence.xml level metadata and additional metadata
the platform provider passes to the persistence provider to control
or configure the operations outlined above.


I am assuming for that Java EE 7 we need to support both the
separate database and shared database (aka separate schema)
approaches.

I am also assuming that it is the platform provider that does the
provisioning of either the database or the schema respectively
(i.e.,
in accordance with whether the separate database or shared database
approach is taken). I.e., in the separate database approach, I'm
assuming that it is the persistence provider that creates the
schemas
directly in the database or creates the DDL to generate the schemas
needed for the persistence unit. [I'll use the term "schema
generation" generically below to mean either table generation or
schema+table generation with this assumption in view.]


Here's a proposal to get the discussion started.

SCHEMA GENERATION

I think we should allow schema generation to be done either as a
deployment (or pre-deployment) phase or at createEMF time.

Deployment-time (or predeployment-time) schema generation could be
done either by the platform provider calling into the
PersistenceProvider implementation to generate the database
schema or
by the platform provider running SQL DDL scripts.

SQL DDL scripts might be provided with the application (bundled as
part of the persistence unit) or the platform provider might invoke
the PersistenceProvider implementation to generate them from the
persistence unit metadata. If scripts are provided or generated, it
should be the platform provider's responsibility to run them against
the database. If the application has provided DDL scripts, the
application should also have the option to provide SQL scripts to do
a bulk insert of data. It would be the responsibility of the
platform provider to run these as well.

An alternative to the use of scripts is for the platform provider to
call into the PersistenceProvider to directly generate the tables in
the database. In the case that a database has been provisioned
rather
than only a schema, the persistence provider would generate the
schemas and tables.

For the sake of argument, let's assume that we add a
generateSchema()
method to the PersistenceProvider interface, which the platform
provider invokes during the deployment phase if SQL scripts have not
been provided by the application.

Information that needs to be passed in would include the following:

(1) Information that specifies how schema generation is to proceed.
This information could take the form of a SchemaGenerationInfo
interface or it could be in the form of additional standard
properties.
(2) Connection to the database or schema. [Is this a Connection or a
DataSource ?]
(3) PersistenceUnitInfo


The SchemaGenerationInfo should include the following:

ddl-generation-mode: GENERATE_AND_EXECUTE | GENERATE_ONLY |
EXECUTE_ONLY

GENERATE_AND_EXECUTE => generate ddl scripts and generate schema (if
applicable) and tables directly in the database

GENERATE_ONLY => generate ddl scripts

EXECUTE_ONLY => generate schema (if applicable) and tables
directly in
the database

create-ddl-target: a Writer configured for the persistence provider
for outputting of the DDL scripts for the creation of schema/tables.
This should be null if EXECUTE_ONLY ddl-generation-mode is
specified.

drop-ddl-target: a Writer configured for the persistence provider
for outputting of the DDL scripts for the dropping of schema/tables.
The should be null if EXECUTE_ONLY ddl-generation-mode is specified.

ddl-execution-mode: Used when executing directly against the
database,
rather than generating scripts. Options should include:
CREATE_TABLES | DROP_TABLES | DROP_AND_CREATE_TABLES
Do we also need to distinguish CREATE_SCHEMAS_AND_TABLES ?
DROP_SCHEMA ?
Or can these be implicit?
Do we also need an ALTER_TABLES capability here?

properties: These could include any vendor-specific properties


ADDITIONAL METADATA (persistence.xml)

If scripts are provided with the application (i.e., bundled as part
of the persistence unit), we should add entries in the
persistence.xml
to identify them:
create-ddl-script
drop-ddl-script
data-load-script(s) [Do we need to support more than one load
script?
If so, the ordering may need to be specified as well.]

Open issue: do we need metadata in the persistence.xml for
ddl-execution-mode as well? For example, this might be used in
standalone scenarios (?)


ORM METADATA (annotations and orm.xml)

(1) Indexes

I think we need to support indexes.

Here's a strawman annotation:

@Target({}) @Retention(RUNTIME)
public @interface Index {
String name() default "";
String columnList();
}

The columnList syntax could follow that of the OrderBy annotation:

columnList::= indexColumn [, indexColumn]*
indexColumn::= columnName [ASC | DESC]

If ASC or DESC is not specified, ASC is assumed

We'd also need to add
Index[] indexes() default {};
to Table, Secondary Table, CollectionTable, JoinTable, and
TableGenerator


(2) Foreign Key Constraints

I see two possible approaches:

(a) Add a string-valued foreignKeyDefinition element to JoinColumn,
JoinColumns, MapKeyJoinColumn, etc. to specify a SQL fragment
(intended along the lines of columnDefinition) for defining a
foreign
key constraint and/or for overriding the persistence provider's
default foreign key definition. It might also be helpful to allow a
name for the foreign key constraint to be specified for the case
where
the provider is using its default foreign key generation strategy.

or

(b) Add a ForeignKey annotation to specify the foreign key
constraint --
for example,

public @interface ForeignKey {
String name() default "";
ForeignKeyAction updateAction() default NO_ACTION;
ForeignKeyAction deleteAction() default NO_ACTION;
boolean deferred() default false;
}

public enum ForeignKeyAction {NO_ACTION, CASCADE, SET_NULL};

I have some misgivings about approach (b), and, given a lack of
database portability here, we might wind up needing a
foreignKeyDefinition
fragment anyway.


(3) Other

What about the ability to distinguish a CHAR rather than VARCHAR
mapping for strings? Or should we just leave this as belonging in a
SQL fragment (with the understanding that we would be intentionally
discouraging the use of CHAR strings)?

(4) Anything else I'm missing?


APIs

I assumed the addition of a PersistenceProvider.generateSchema()
method
above.

If we also support schema generation at EMF creation time, do we
want
another createContainerEntityManagerFactory() method that takes a
SchemaGenerationInfo as well as PersistenceUnitInfo argument ?

If generation is done directly in the database, at some point the
container (or application) may need to have the schema/tables
dropped.
I'm not sure of the best way to support this. A dropAndClose()
method
on the EMF??





[jsr338-experts] JPA schema generation

Linda DeMichiel 05/09/2012

[jsr338-experts] Re: JPA schema generation

Evan Ireland 05/09/2012

[jsr338-experts] Re: JPA schema generation

Nicolas Seyvet 05/10/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/15/2012

[jsr338-experts] Re: JPA schema generation

Steve Ebersole 05/15/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/15/2012

[jsr338-experts] Re: JPA schema generation

Steve Ebersole 05/15/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/15/2012

[jsr338-experts] Re: JPA schema generation

Steve Ebersole 05/15/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/21/2012

[jsr338-experts] Re: JPA schema generation

Rainer Kwesi Schweigkoffer 05/22/2012

[jsr338-experts] Re: JPA schema generation

Gordon Yorke 05/15/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/15/2012

[jsr338-experts] Re: JPA schema generation

Gordon Yorke 05/15/2012

[jsr338-experts] Re: JPA schema generation

Steve Ebersole 05/17/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/18/2012

[jsr338-experts] Re: JPA schema generation

Steve Ebersole 05/18/2012

[jsr338-experts] Re: JPA schema generation

Linda DeMichiel 05/18/2012

[jsr338-experts] Re: JPA schema generation

Steve Ebersole 05/21/2012
 
 
Close
loading
Please Confirm
Close