Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] bug 340329 - table creation prefix 
Hi Tom,

one could also imagine to (optionally) allow specifying a database[platform] for a CREATE TABLE suffix/prefix/infix:

<table name="DDL_COMMENT" creation-suffix=" engine=InnoDB" database="MySQL"/>

or 

<table name="DDL_COMMENT" creation-suffix=" engine=InnoDB" database="org.eclipse.persistence.platform.database.MySQLPlatform"/>

With the "database" element present, the suffix/prefix/infix would be applied for this database platform only. If absent it would be applied always.

Still an @DDL annotation or alike would be way more powerful. But I'd opt to have this database-dependent as well. I could also imagine to address this in JPA 2.1.

-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: Dienstag, 29. März 2011 14:30
To: Dev mailing list for Eclipse Persistence Services
Cc: Singer, Reiner
Subject: Re: [eclipselink-dev] bug 340329 - table creation prefix

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

Back to the top