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:
1.
Allow a developer to specify a suffix for the CREATE DATABASE at the
PU level or specifically on a given entity's table(s)
2.
Allow a developer to specify a prefix for the CREATE DATABASE at the
PU level or specifically on a given entity's table(s)
3.
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