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 "EclipseLink/DesignDocs/Extensibility"
(→Use Case for Extensibility) |
|||
| Line 65: | Line 65: | ||
=== Extension Design === | === Extension Design === | ||
| − | The second phase of design involves customization of the persistence unit. With the persistence unit already deployed, the | + | The second phase of design involves customization of the persistence unit. With the persistence unit already deployed, the user doing customization adds mappings to the persistence unit. Because the schema has been designed to accomodate the new mappings, EclipseLink can either make use of predefined tables and columns to store the data for the mappings, or alter the schema to add new columns to existing tables. |
| + | |||
| + | ==== Example ==== | ||
| + | |||
| + | The user of the order processing system above decides to extend it. They with to add an "address" attribute to Customer. | ||
| + | |||
| + | The user calls EclipseLink API to add a mapping to the metadata. EclipseLink adjusts the users underlying session to make use of the mapping. Future retreivals using Customer make use of the new "address" mapping. | ||
==== Example ==== | ==== Example ==== | ||
Revision as of 12:59, 12 January 2011
UNDER CONSTRUCTION
Contents
Extensibility
The goal of this feature is to allow a user to start with a predesigned persistence unit and extend the entities in that persistence unit without redeployment. Extensibility is a prerequistie for Multi-tenancy.
For example, a simple application is provided that defines a Customer entity that maps "name" and "customer number". As the application is running, the Customer application can be extended to include a "company name" mapping.
In the above example, the addition of the "company name" is acheived only through interaction with EclipseLink. EclipseLink should handle schema modifications (if any) and any adjustment to EclipseLink metadata and Session.
Use Case for Extensibility
When we have completed our extensibility work, it will be possible for a persistence unit to be designed in two phases.
Pre-defined Mapping Design
The first phase will be nearly identical to the way a persistence unit is designed in EclipseLink today. In this phase of design the base schema, mappings, and properties of the persistence unit are defined. These parts of the persistence unit will exist for all running applications.
There will be some differences from typical persistence unit design, and they will potentially include:
- Creation of additional tables in the schema
- Adding additional columns to tables in the schema
- Providing additional privileges for schema alteration
- Specification of which Entities are extensibible
Example
The user designs a system for processing orders. They define the following Entities:
- Customer
- @Id id
- @Basic name
- @OneToMany Orders
- Order
- @Id id
- @OneToOne Item
- @Basic quantity
- @ManyToOne customer
- Item
- @Id id
- @Basic name
- @Basic unitPrice
The mappings are made using JPA annotations, orm.xml or a combination, in the same way as other JPA applications. A persistence.xml is provided to configure the persistence unit.
The user designs a database schema to hold their Entities. The schema includes the following tables:
- CUSTOMER
- INTEGER ID
- VARCHAR NAME
- ITEM
- INTEGER ID
- INTEGER ITEM_ID
- INTEGER QUANTITY
- INTEGER CUST_ID
- ORDER
- INTEGER ID
- VARCHAR NAME
- FLOAT PRICE
Depending on their extensibility strategy, they may define other columns in those tables or other tables. This will be discussed more in Schema Design Section below.
The persistence unit is assembled and deployed. At this point it can be used.
Extension Design
The second phase of design involves customization of the persistence unit. With the persistence unit already deployed, the user doing customization adds mappings to the persistence unit. Because the schema has been designed to accomodate the new mappings, EclipseLink can either make use of predefined tables and columns to store the data for the mappings, or alter the schema to add new columns to existing tables.
Example
The user of the order processing system above decides to extend it. They with to add an "address" attribute to Customer.
The user calls EclipseLink API to add a mapping to the metadata. EclipseLink adjusts the users underlying session to make use of the mapping. Future retreivals using Customer make use of the new "address" mapping.
Example
Schema Design for Extensibility
The following are some data-model extensibility options
Flex Columns
Schema is designed to include preallocated columns that can be used to map additional data.
e.g. Customer table has colums NAME, CUST_NUMB, DATA1, DATA2 etc. "company name" is mapped to DATA1.
Custom Columns
EclipseLink alters tables as needed.
e.g. Customer table has colums NAME, CUST_NUMB. When "company name" is added to Customer, a COMPANY_NAME column is added to the table by EclipseLink using an ALTER TABLE call.
Value Rows
Extra data is stored in a Map structure.
e.g. Customer table has colums NAME, CUST_NUMB. A table exists with columns ATTR_NAME, ATTR_VALUE, OWNER_ID, OWNING_ENTITY. That column holds the names of any new attributes, their values, a foreign key to the owner, and a way of determining which Entity the mapping belongs to.
Metadata
API
API will be provided to query, create and delete new mappings
Metadata Storable
DB table store metadata for extended fields. It is accessed at login time, prior to descriptor initialization.
Metadata access
Metadata is accessible through an Interface. (user defined?)
Multi-tenancy discussion
The following multi-tenancy discussion doc was used in the discussion of this feature
Multi Tenant Features: Description of features available and being considered for Multi Tenant APPs