Community
Participate
Working Groups
It would be nice if EclipseLink would allow the user to define indices as part of the DDL-generation process. Hibernate allows this via their @Index annotation, and OpenJPA allows this via *their* @Index annotation.
JDO defines this too. The lack of this feature makes EclipseLink unusable for us. Have the designers ever considered the scenario of an application with an embedded database where there simply is no DBA to create the indexes separately?
Fixed. @Index and @Indexes annotations were added. You can define them on an Entity or on an attribute to easily index that attribute.
Created attachment 177846 [details] patch
re-opening to visit some comments and questions surrounding the metadata processing: 1- I didn't seen any schema (eclipselink_orm_2_2.xsd) changes in the diff? 2- if processIndexes is called for all mapping accessors, you can just call it in the setMapping method off MappingAccessor. 3- It looks like Index(es) from annotations get appended to those from XML, intended? XML specification should override annotations. 4- If the processIndexes method is identical in both EntityAccessor and MappingAccessor could it not move up to MetadataAccessor? 5- Entities can not inherit Indexes from a MappedSuperclass? 6- What about indexes columns from an embeddable? Attribute-overrides? 7- The indexes should be added to the merge from EntityAccessor. This is XML mapping file merging. This also means IndexMetadata would need a unique identifier (implement String getIdentifier()), in this case the index name? 8- There seems to be a disconnect from schema and catalog on IndexMetadata and the Index annotation, that is, I don't see them on the annotation. 9- Also during processing, these values (schema and catalog) if not set directly on the index, they should check for an entity mappings or persistence unit default setting (through the descriptor) 10- The name, schema and catalog context from IndexMetadata are re-using the @Table contexts (from MetadataLogger) probably should have its own contexts (used for logging defaulting messages) 11- IndexMetadata should extend TableMetadata? If it did you could call processTable from MetadataAccessor (in the processIndexes method) with your index metadata which would correct point #9 for you. It would also employ the contexts from point #10 12- The OXM mappings must remain in the same order as the elements are defined in the schema otherwise on write out OX will write the elements out in the wrong order. Not sure if this case applies here as I can't see any schema changes but wanted to mention it.
Added bug to our tracking wiki for EclipseLink orm 2.2 extensions: http://wiki.eclipse.org/EclipseLink/Development/2.2/AdvancedJPA#Eclipselink_ORM
Created attachment 178846 [details] updated patch
Updated patch. 1- I didn't seen any schema (eclipselink_orm_2_2.xsd) changes in the diff? -- forgot, updated the schema, also updated the DDL tests to validate the XML as they should not have been passing 2- if processIndexes is called for all mapping accessors, you can just call it in the setMapping method off MappingAccessor. -- changed to just process for basic, indexes on other mappings don't really make sense, or would be too complicated at least 3- It looks like Index(es) from annotations get appended to those from XML, intended? XML specification should override annotations. -- I assume they would be adding additional indexes in XML, not overriding, so am adding them 4- If the processIndexes method is identical in both EntityAccessor and MappingAccessor could it not move up to MetadataAccessor? -- they are subtly different, mainly in their defaults, now more different as changed basic to only allow a single index 5- Entities can not inherit Indexes from a MappedSuperclass? -- no mapped superclass support, they do not have a table, so no index. You would need to define the index in each subclass if desired. 6- What about indexes columns from an embeddable? Attribute-overrides? -- no embeddable support, they do not have a table, so no index. You would need to define the index in each Entity if desired. 7- The indexes should be added to the merge from EntityAccessor. This is XML mapping file merging. This also means IndexMetadata would need a unique identifier (implement String getIdentifier()), in this case the index name? -- updated the merge 8- There seems to be a disconnect from schema and catalog on IndexMetadata and the Index annotation, that is, I don't seem them on the annotation. -- oops, added them 9- Also during processing, these values if not set directly on the index, they should check for an entity mappings or persistence unit default setting (through the descriptor) -- they were? 10- The name, schema and catalog context from IndexMetadata are re-using the @Table contexts (from MetadataLogger) probably should have its own contexts (used for logging defaulting messages) -- methods didn't have any senders, so I removed them 11- IndexMetadata should extend TableMetadata? If it did you could call processTable from MetadataAccessor (in the processIndexes method) with your index metadata which would correct point #9 for you. It would also employ the contexts from point #10 -- no, index is not a table, it can process its own defaults 12- The OXM mappings must remain in the same order as the elements are defined in the schema otherwise on write out OX will write the elements out in the wrong order. Not sure if this case applies here as I can't see any schema changes but wanted to mention it. -- fixed
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
