Talk:EclipseLink/DesignDocs/214519

Everything in @ELTable should be optional and the contents should override that of @Table.
What about a calling the annotation @TableExt (Ext for extension) or @TableOverrides or something else?
Gordon Yorke 13:58, 1 October 2010 (UTC)

---

Naming & Annotation?

--Doug 13:58, 5 October 2010 (UTC)

A couple of comments:

1. eclipselink.ddl.default-table-suffix: is it really a table suffix? That name implies to me additional text added to the table name. Its really a suffix added to CREATE TABLE command
2. @ELTable annotation? I do not like duplicated @Table in @ELTable
   • Do we even need an annotation? Is PU property and eclipselink-orm.xml enough?

James.sutherland.oracle.com 12:40, 13 October 2010 (UTC)

I really dislike @ELTable. Extension annotation should not duplicate existing annotations, but just annotate the extension.

i.e. we have @JoinFetch not an @ELOneToOne that has a joinFetch attribute, @ReadOnly not @ELEntity with a readOnly attribute,

and we already extend tables using @Index not @ELTable with indexes

We should just have an @TableCreationSuffix(tableName=<defaults to descriptor/mapping table>, value=" engine=InnoDB")

Also the reason for adding this is to support MySQL InnoDB, and the only reason we need to do this is that the DatabasePlatform is not :given any hook during table creation to modify the tables. We should also provide a hook during table creation to allow the :DatabasePlatform to modify the TableDefinitions or their DDL.

@ELTable

I orginally mocked up using an @ELTable to replace everything in @Table when it is defined, but thought that the two having duplicate data might cause confusion with users defining @Table and expecting the information to be used. Doing so would mean having to maintain duplicate information for users who wish to keep to the JPA specification as close as possible and still use EclipseLink DDL generation features.

The alternative is an Eclipselink annotation that supplements @Table, such that other than the name attribute, nothing overlaps. If the new annotation is specified, it would be merged into the defined (or defaulted) table with the same name. As Gordon suggested, name too should be optional, and a warning/exception given when the annotation is applied to a spot where there is no table of that name defined or a name not defined and there is more than one table defined.

What I see creation suffixes at the individual table level being used for is performance tuning of production apps, and it maybe of little value to early application development that DDL generation seems more aimed at. From a code implementation perspective, overriding the @Table annotation is slightly less complex than merging into it, but either way both will be less than elegant due to tables being handled differently in the different annotation processing classes for each mapping type. In contrast, the changes to support a creation suffix at the table level in XML are almost free - on top of the changes to support the creation suffix at the session level, all that is required is changes to the eclipseLink-orm.xml and an extra mapping for the 4 xml tags affected.

property name default-table-creation-suffix

I switched the property name to eclipselink.ddl.default-table-creation-suffix which seems verbose but more accurate. Another option might be eclipselink.ddl.default.table-creation-suffix, if we see the value in adding other eclipselink.ddl.default properties in the future.

Default?

I would leave default out of the property name. It is the suffix and if we ever do table level config they would override this value. --Doug 01:01, 8 October 2010 (UTC)