Difference between revisions of "Talk:EclipseLink/DesignDocs/340192"

Latest revision as of 11:46, 26 April 2011

The EXTENSION_DEF has no way of matching rows to fields in the Customer table.

EXTENSION_DEF requires a field to store the referenced field name (in the flexfield case). This allows custom naming to be used, and ensures the EXTENSION_DEF rows match up consistently to the same fields. It also makes the sequence id field unnecessary, as the ENT_NAME and this fieldName reference would uniquely identify it.

• I agree --Tom.ware.oracle.com 18:19, 28 March 2011 (UTC)

ExtensionProperties will also need a way to represent multiple fields - such as a 1:1 to an entity with composite foreign keys. Either the ExtensionProperty will need to represent multiple rows in the EXTENSION_DEF table, to be more along the lines of what a mapping is in EclipseLink, or addExtension potentially result in creating multiple ExtensionProperties.

If an extension has multiple ExtensionProperties, this can easily be contained in a map keyed on the extension name, with a collection of ExtensionProperties as the value.

• We are currently not planning on supporting composite keys in relationship mappings for the first iteration of this feature. (even 1-1 is currently listed as a SHOULD and not a MUST) I believe we should carefully design our public API to not preclude using composite keys at a later day, but other than that, should not necessarily include composite key support in our initial design. --Tom.ware.oracle.com 18:19, 28 March 2011 (UTC)

Overview

I think the document needs an overview discussion the types of applications we intend to support and why they need this extension. In terms of the existing table having extra columns, would it not be significantly simpler for the user to just add extra fields to their class mapped to these extra columns? What benefit do users get from our Flex support?

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

Added some comments to the overview to cover the main usecase

--Tom.ware.oracle.com 19:24, 31 March 2011 (UTC)

OneToOne

Not exactly sure how this will work, and would seem to need a lot more flexibility to really work. How can a VARCHAR field be a foreign key to a NUMERIC column? Also issues with composite ids, cascading, fetching, etc. We should probably not add support for OneToOne until we are will to do it properly, and probably support any mapping type.

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

FlexExtensions

Seems like this annotation should be defined on the class and named similar to sequences and referenced from the Map (@Flex(name="default-flex")). This would save the user from having to add the same annotation to every class.

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

createNonExistingColumns is kind of complex, what about just alterTable.

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

extensionTableName should probably be an @Table to allow qualifier, constraints, etc.

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

Making it @Table will create a dependency between our core project and the javax.persistence library. That is not possible. A number of other annotations use just table name, so at the moment, I am leaning towards keeping table name. The other option is to create our own @FlexExtensionTable annotation that mirroirs @Table

--Tom.ware.oracle.com 19:34, 31 March 2011 (UTC)

Huh? The dependency already exists, many of the existing annotations use the JPA annotations.

In general we should move the annotations package to JPA.

James.sutherland.oracle.com 14:54, 6 April 2011 (UTC)

JpaHelper API - is this required? Why not just have getExtensionsManager on JpaEntityManager or Factory (probably JpaEntityManager as you cannot unwrap the factory is JEE). Didn't the JPA 2.0 unwrap API obsolete JpaHelper?

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

Good idea. Fixed.

--Tom.ware.oracle.com 19:28, 31 March 2011 (UTC)

TYPE - Cannot use reserved word as a column name.

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

Changed to TARGET_TYPE

--Tom.ware.oracle.com 19:26, 31 March 2011 (UTC)

Descriptor Initialization

How do you intend to add new mappings to a descriptor at runtime? How will the descriptor be reinitialized, how will the SQL for existing query be regenerated? What happens to concurrent threads accessed the descriptor as the new mappings are being added? What about the existing cached objects, how do they get the new data?

James.sutherland.oracle.com 18:50, 31 March 2011 (UTC)

Metadata Repository

• the API to retrieve extensions should probably return an XMLEntityMappings instance which can then be merged/used directly by metadata processing. This allows different stores to build XMLEntityMappings directly instead of building an el-orm.xml and then converting to a stream and EL converting it to XMLEntityMappings.

+1 for API to not deal with el-orm.xml

I would say even XMLEntityMappings is too coarse of a data structure to return for defining extensions. How would an implmentor create instance of XMLEntityMappings to be retruned? Why can't we just let the API return a data structure that just deals with extensions. This correspond to the new fields that you will need to add to XMLEntityMappings to represent the extensions.  mitesh.meswani.oracle.com 20:57, 25 April 2011 (UTC)

The current plan is that extensions are defined using a sparse eclipselink-orm.xml file (containing only the new mappings). If a MetadataRepository implementation can provide a Reader attached to a stream in that format, EclipseLink will do the reading and conversion that includes makes it into an XMLEntityMappings. There is quite alot of information we have to produce store for each mapping and eclipselink-orm.xml is designed to capture that very information. Additionally, there are tools that can produce an eclipselink-orm.xml file. It is not clear to me what the specific concern about this approach is. --Tom.ware.oracle.com 13:31, 26 April 2011 (UTC)

• Refresh seems more related to the EntityManagerFactoryImpl, with the repository serving up the mappings on demand. From design, the refresh method is going to have to tell the EMF to reload with data from the repository, so the EMF needs a reload/refresh method anyway.

• Including API to store extensions and cause them to be used might be better left outside the Repository class, for instance in its own interface that a Repository implementation can also implement later on. This would keep the repository class an EclipseLink item that does not need to be exposed to the user for the first iteration, with the new interface structure what might be exposed to customers wishing to manipulate their repository data.

• MetadataRepository should be an interface, not class. You can also add an AbstractMetadataRepository to make implementation easier.
• Should have a retrieve and a store method.

James.sutherland.oracle.com 15:43, 26 April 2011 (UTC)

Weaving

• Instead of throwing an exception, another option would be to log a warning and not weave the class.

--Christopher.delahunt.oracle.com 19:15, 25 April 2011 (UTC)

• Why does weaving have a restriction on basic types?

James.sutherland.oracle.com 15:44, 26 April 2011 (UTC)

Virtual

• Why does descriptor have virtualGetMethodNames, shouldn't it be just one method?

James.sutherland.oracle.com 15:46, 26 April 2011 (UTC)