Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/DesignDocs/340192"
| Line 1: | Line 1: | ||
= Flex Columns Extension = | = Flex Columns Extension = | ||
| + | |||
== Overview == | == Overview == | ||
| Line 13: | Line 14: | ||
An arbitrary number of the columns prefixed with "FLEX_COL" could be defined. A user mapping the "address" property of Customer could simply map it to FLEX_COL1. | An arbitrary number of the columns prefixed with "FLEX_COL" could be defined. A user mapping the "address" property of Customer could simply map it to FLEX_COL1. | ||
| + | == Requirements == | ||
| + | |||
| + | * Users MUST be able to add extensions at Runtime | ||
| + | * Extensions MUST be persistent. (i.e. Extensions must continue to exist if an application goes down and comes back up) | ||
| + | * Extensions MUST be compatible with our multi-tenant features. (i.e. Extensions must be able to make use of our Multi-tenant features to be definable on a tenant by tenant basis) | ||
| + | * Extensions MUST have DDL Generation support | ||
| + | * BasicMappings MUST be supported | ||
| + | * OneToOneMappings SHOULD be supported | ||
| + | |||
| + | ---- | ||
In order to support multiple data types, all flex-columns are defined as strings. Metadata about the expected type of the field is defined in the database. For each flex column, there is a set of entries in a database table. The table and column names storing these items could be Application provider determined and therefore they could all exist on the same table or they could exist on different tables. | In order to support multiple data types, all flex-columns are defined as strings. Metadata about the expected type of the field is defined in the database. For each flex column, there is a set of entries in a database table. The table and column names storing these items could be Application provider determined and therefore they could all exist on the same table or they could exist on different tables. | ||
Revision as of 14:07, 16 March 2011
Flex Columns Extension
Overview
Schema is designed to include preallocated columns that can be used to map additional data. In this example, Customer table might look like this:
- CUSTOMER
- INTEGER ID
- VARCHAR NAME
- VARCHAR FLEX_COL1
- VARCHAR FLEX_COL2
- VARCHAR FLEX_CO31
An arbitrary number of the columns prefixed with "FLEX_COL" could be defined. A user mapping the "address" property of Customer could simply map it to FLEX_COL1.
Requirements
- Users MUST be able to add extensions at Runtime
- Extensions MUST be persistent. (i.e. Extensions must continue to exist if an application goes down and comes back up)
- Extensions MUST be compatible with our multi-tenant features. (i.e. Extensions must be able to make use of our Multi-tenant features to be definable on a tenant by tenant basis)
- Extensions MUST have DDL Generation support
- BasicMappings MUST be supported
- OneToOneMappings SHOULD be supported
In order to support multiple data types, all flex-columns are defined as strings. Metadata about the expected type of the field is defined in the database. For each flex column, there is a set of entries in a database table. The table and column names storing these items could be Application provider determined and therefore they could all exist on the same table or they could exist on different tables.
- Label (e.g. address)
- Type (e.g. java.lang.String)
For instance, for the above example, an Application Provider might choose to define a single table containing the columns
- CUSTOMER_METADATA
- FLEX_COL1_LABEL
- FLEX_COL1_TYPE
- FLEX_COL2_LABEL
- FLEX_COL2_TYPE
- FLEX_COL3_LABEL
- FLEX_COL3_TYPE
Alternatively, they might choose two define 3 tables
- CUSTOMER_COL1_METADATA
- FLEX_COL_LABEL
- FLEX_COL_TYPE
- CUSTOMER_COL2METADATA
- FLEX_COL_LABEL
- FLEX_COL_TYPE
- CUSTOMER_COL3METADATA
- FLEX_COL_LABEL
- FLEX_COL_TYPE
Initially these tables would be quite sparse, but with the addition of Multi-tenant features they would become better populated