Hi,
I like this proposal a lot because
it promises ultimate flexibility. But I don’t think the @DDL
annotation should have a member “ddl”. I’d prefer “drop” and
“create”.
How about:
@DDLs{
@DDL(suffix="engine=InnoDB", platforms="MySQL")
@DDL(create="CREATE
TABLE blah ... tablespace X, initial size 512m",
override=true, platforms="Oracle")
@DDL(drop="DROP
TABLE blah CASCADE CONSTRAINTS", type=DROP,
platforms={"Oracle"})
}
Also, I am afraid that the @DDL
annotations will get quite lengthy. Maybe one could
alternatively refer to a file, e.g.
@DDL(createScript=”ddl-scripts/person_create_oracle.sql”,
platforms=”Oracle”)
-Adrian
DDL would allow more
than just table creation, (indexes, constraints, types,
tablespaces, etc.)
I think having
multiple different nested annotations is too complex.
Just have a single DDL and follow the normal collection
pattern with an array annotation.
override is require
as it may be overriding the table DDL, or may be DDL for a
constraint or index on the existing table.
A type could be
added to define when the DDL should be executed.
@DDLs{
@DDL(suffix="engine=InnoDB", platforms="MySQL")
@DDL(ddl="CREATE
TABLE blah ... tablespace X, initial size 512m",
override=true, platforms="Oracle")
@DDL(ddl="DROP
TABLE blah CASCADE CONSTRAINTS", type=DROP,
platforms={"Oracle"})
}
SQL = structured
query language (querying, does not include ddl)
DDL = data
definition language (creating database types/objects)
-----Original
Message-----
From: douglas clarke
Sent: Tuesday, April 05, 2011 1:57 PM
To: eclipselink-dev@xxxxxxxxxxx
Subject: Re: [eclipselink-dev] bug 340329 - table
creation prefix
James,
Interesting. Some feedback on this proposal:
·
I
like the idea of being able to specify the full create table
string similar to how @Column allows you to specify a
replacement columnDefinition.
·
I
don't love the idea of an annotation being an acronym. I
would prefer to see an annotation that is more readable as
to what it will do.
·
If
you can provide a create string or suffix for one or more
database platforms then you should be able to specify
multiples
·
I
prefer the platform names used in TARGET_DATABASE
("eclipselink.target-database") property and believe we
should take strings and process them in a similar fashion
using the string as a class name if a short name match is
not found
·
Unsure
what exactly you mean by override. If the full sql is
provided it is used as is. If a suffix is provided it is
used in conjunction with the generated sql. If no value is
provided for the current platform then the default generated
sql is used.
·
Should
we include specifying the DROP TABLE syntax for specific
platforms as well so I could get the CASCADE CONSTRAINTS
included on platforms that support it.
As a rough idea we could support something like:
@Entity
@Table(name="BLAH")
@DDL(
create={
@CreatTable(suffix="engine=InnoDB"
platforms="MySQL"),
@CreateTable(sql="CREATE TABLE blah
... tablespace X, initial size 512m" platforms="Oracle")
}
drop=@DropTable(sql="DROP TABLE blah CASCADE
CONSTRAINTS", platforms={"Oracle"})
)
public class Blah {
...
On 04/04/2011 8:39 AM, James Sutherland wrote:
I don't think we
should be using descriptor properties for this (or any)
feature.
If we have a
specific feature, we should have a specific annotation for
it.
I would propose,
@DDL(ddl, table,
suffix, override, databases)
.i.e
@DDL(suffix="engine=InnoDB",
databases=MySQLPlatform.class)
@DDL(ddl="create
hash index empname_inx on employee by name")
@DDL(ddl="create
table employee (id numeric(20), name varchar2(512))
tablespace amce3, initial size 512m, overrude=true,
databases=OraclePlatform.class)
I don't think we
should add infix or prefix unless we have valid examples
of these. I do not know of any, other than "temporary"
which is not relevant.
Please give concrete
examples for this feature.
-----Original Message-----
From: douglas clarke
Sent: Friday, April 01, 2011 2:43 PM
To: eclipselink-dev@xxxxxxxxxxx
Subject: Re: [eclipselink-dev] bug 340329 - table
creation prefix
The
original issue that lead to the suffix capability was very
specific to the engine=InnoDB usage.
I believe what we are now discussing is a slightly broader
set of requirements around augmenting the CREATE TABLE DDL
statement.
I would say the requirements are now:
Allow a developer to specify a suffix
for the CREATE DATABASE at the PU level or specifically on a
given entity's table(s)
Allow a developer to specify a prefix for
the CREATE DATABASE at the PU level or specifically on a
given entity's table(s)
Allow the developer to specify the platform a
suffix or prefix applies to and only use it in that case
One
approach would be to deprecate the <table suffix support
and extend the existing properties support to apply to
entities and to allow the property to be specified as
platform specific.
PU property (already exists):
"eclipselink.ddl-generation.table-creation-suffix" -
indicates a suffix used on all CREATE TABLES for all
platforms
Add platform support:
"eclipselink.ddl-generation.table-creation-suffix.MySQL" -
indicates a suffix for all CREATE TABLES issued against a
database platform with the short name 'MySQL'.
Then we could extend this support on a per-entity basis
using EclipseLink's properties for cases where a developer
needs to supply these values differently for different
entity table(s).
@Entity
@Properties({
@Property(name="eclipselink.ddl-generation.table-creation-suffix.MySQL",
value="engine=InnoDB"),
@Property(name="eclipselink.ddl-generation.table-creation-prefix.MaxDB",
value="???")
})
public class Foo {
This of course could also be specified in the
eclispelink-orm.xml within an entities's properties tags.
Doug
On 29/03/2011 8:29 AM, Tom Ware wrote:
That's a
reasonable point. In the end, I guess it comes down to a
choice about which is more important to us, the flexibility
or the portability.
My vote is for the flexibility due to the fact that we
currently only know of one suffix and it is not even
necessary if you set your MySQL to use Innodb. DDL
Generation, after all, is only a development-time feature.
I wonder if James' suggesting of a larger DDL config could
be used to address this problem more generally. I guess it
depends on if we want to worry about that larger feature
now, or if it is more important to get the prefix work.
Other committers... What do you think?
-Tom
Goerler, Adrian wrote:
Hi,
We
thought about the delegation model you suggest below. The
weakness is, of course, that it requires a code change to
deal with any property that might be passed in. (i.e. if
MySQL added a new modifier other than INNODB, we'd have to
actually change the MySQLPlatform to support it). So far,
the features that are addressed with the suffix are fairly
obscure, so we thought it would be better to leave it free
form. I am, however open to arguments the other way.
an advantage of the delegation model would be that
properties (or hints) not applicable for the current
database platform would just be ignored. With the free from
suffix, I can't run the same application on two different
database platforms.
-Adrian
Adrian Görler
SAP AG
Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tom Ware
Sent: Montag, 28. März 2011 19:29
To: Dev mailing list for Eclipse Persistence Services
Cc: Singer, Reiner
Subject: Re: [eclipselink-dev] bug 340329 - table creation
prefix
Hi Adrian,
I'd like to hear what other committers think but I think
my preference is to specify this as a "table creation
modifier" or some such thing. (your infix suggestion)
Unless we can think of a case where we would not have
both the "CREATE" and "TABLE" strings, I think it would be
cleaner to avoid requiring they be specified.
We thought about the delegation model you suggest below.
The weakness is, of course, that it requires a code change
to deal with any property that might be passed in. (i.e. if
MySQL added a new modifier other than INNODB, we'd have to
actually change the MySQLPlatform to support it). So far,
the features that are addressed with the suffix are fairly
obscure, so we thought it would be better to leave it free
form. I am, however open to arguments the other way.
-Tom
Goerler, Adrian wrote:
Hi Tom,
yes, a "prefix" as propsed in the patch would substitute
"CREATE TABLE". I agree that "prefix" does not appear to be
the right terminology. "createTableStatement" isn't either
as its only the first part of the statement. Maybe
"createTableKeywords" would be better or
"createTableStatementHeader".
It is an SAP-specific future feature we would like leverage,
which allows to control some storage parameters of a table.
The actual Syntax has the structure "CREATE <modifier>
TABLE". Hence specifying the <modifier> as an "infix"
would also be OK.
Still, I am afraid that this (prefix/suffix) opens a small
can of worms and it might be cleaner to delegate
writeCreateTable to the platform as scetched out below.
-Adrian
Adrian Görler
SAP AG
Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tom Ware
Sent: Montag, 28. März 2011 16:55
To: Dev mailing list for Eclipse Persistence Services
Cc: Xiang, Xu; Singer, Reiner
Subject: Re: [eclipselink-dev] bug 340329 - table creation
prefix
What would a typical prefix be? (is it really a prefix, or
a replacement for "CREATE TABLE"? Is PREFIX the right
terminology?)
When would someone choose to use a prefix? Is this a MAXDB
specific thing?
-Tom
Goerler, Adrian wrote:
Hi Chris,
others,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340329
we got the requirement to allow overriding the CREATE TABLE
keywords in DDL in a table-specific way to leverage special
database features. Xu has proposed to introduce a
creation-prefix attribute to the table-mappings of
eclipselink-orm.xml - analogously to https://bugs.eclipse.org/bugs/show_bug.cgi?id=214519.
Please find attached a revised proposal including test for
this enhancement.
I you are OK with this feature, I would go ahead and check
it in.
-Adrian
PS.
Alternatively, I could consider to specify additional
requirements on the DDL using @Properties/@Property
annotations. Then, one could add hese properties to the
TableDefinition, redirect rendering of CREATE TABLE
statements to the DatabasePlatform and render the statement
in a database-vendor specific way according to the
properties recognized by the vendor.
E.g.:
@Table(name="MY_TABLE")
@Property("mysql.jdbc.engine", "InnoDB")
@Entity
Public class MyEntity
This, however, would obsolete the creation-suffix just
introduced in 2.2 ;-).
*Adrian Görler
**SAP AG
*Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev