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
|