Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:EclipseLink/DesignDocs/340192"
m |
|||
| Line 4: | Line 4: | ||
This allows custom naming to be used, and ensures the EXTENSION_DEF rows match up consistently to the same fields. | 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. | It also makes the sequence id field unnecessary, as the ENT_NAME and this fieldName reference would uniquely identify it. | ||
| + | |||
| + | * I agree --[[User:Tom.ware.oracle.com|Tom.ware.oracle.com]] 18:19, 28 March 2011 (UTC) | ||
| + | |||
----- | ----- | ||
| Line 12: | Line 15: | ||
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. | 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. --[[User:Tom.ware.oracle.com|Tom.ware.oracle.com]] 18:19, 28 March 2011 (UTC) | ||
Revision as of 14:19, 28 March 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)