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/MultiTenantFeatures"
| Line 53: | Line 53: | ||
| − | == Different Schema == | + | === Different Schema === |
If the tenants are all deployed on different databases or on different table spaces, the tables can quite simply be different. This can be enabled by EclipseLink's table creation feature. Additionally, it would be possible to introduce an EclipseLink feature that could alter tables in an initial schema based on different metadata. | If the tenants are all deployed on different databases or on different table spaces, the tables can quite simply be different. This can be enabled by EclipseLink's table creation feature. Additionally, it would be possible to introduce an EclipseLink feature that could alter tables in an initial schema based on different metadata. | ||
| Line 78: | Line 78: | ||
Attributes are stored in a table that contains a key, an attribute name, and an attribute value. The table could optionally have a foreign key that mapped to a source table. | Attributes are stored in a table that contains a key, an attribute name, and an attribute value. The table could optionally have a foreign key that mapped to a source table. | ||
| + | |||
| + | e.g. Employee table contains an id (and possibly some of the data). Attributes are contained in a table that contains a foreign key to the Employee table, an attribute name and an attribute value. | ||
| + | |||
| + | With this strategy, the map table could contain all the attributes, or the main table could contain some of the attributes and the map table could contain the rest. | ||
| + | |||
Revision as of 15:28, 7 December 2010
UNDER CONSTRUCTION
Contents
Purpose
EclipseLink provides a number of features that help with the challenges of developing multi tenant applications. This document will provide an overview of some of the ways EclipseLink can be used to support multi tenant applications.
In particular, this document will focus on applications where the application provider provides a core application and the tenant needs to extend the data provided in the application. (like Oracle Applications flex columns)
e.g. The application provider provides an Employee class that includes name and address. The tenant also wants to store the Employee Number. How can the application be architected to make storing that kind of extra data easy.
From a persistence-layer point of view, there are two areas where you must design to allow extra data.
- The object model and metadata
- The database
We will outline the options for both areas.
Object Model and Metadata
There are a number of different ways EclipseLink can support added fields in the object model.
Predefined fields
In this case, a class is designed with several generically named and typed fields. Those fields may be used by the tenant to store any data they choose. Converters could be used to control the data types coming out of the fields.
e.g. Employee contains fields called name, address, attribute1, attribute2 etc... The tenant chooses to store employee number in attribute1.
Dynamic JPA
Dynamic JPA allows the construction of a completely metadata driven application. The provider writes a dynamic JPA application that defines the set of classes and attributes that exist. The tenant calls API or provides XML that describes the additional fields on those classes.
e.g. Employee is a dynamically created entity containing name and address attributes. The tenant is allowed to construct a mapping for Employee Number by constructing an EclipseLink-orm.xml file that defines Employee with the new attribute.
Static Classes + Dynamic JPA
A static object model is provided by the provider that defines all the shared attributes. The tenant is provided with mechanism to provide extensions through Dynamic JPA. They are allowed to construct new mappings on the static classes by providing XML that describes fields that will be added to the existing object model through dynamic JPA.
e.g. Employee is a class that contains name and address attributes. The tenant is allowed to construct an eclipselink-orm.xml file that adds a virtual Employee Number field to Employee. EclipseLink's dynamic JPA functionality handles adding the field.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=331915 for the remaining work required for this configuration.
Map
Additional attributes are specified in a Map Mapping. Business logic is used to expose the fields in the Map as standard data.
e.g. Employee has attributes name and address and also a map for additional properties. To add Employee number, the tenant adds a Map Entry with key=EmployeeNumber and Value=<employees Employee Number>
Database
There are many different database architectures that can be used to support storing extra data.
Different Schema
If the tenants are all deployed on different databases or on different table spaces, the tables can quite simply be different. This can be enabled by EclipseLink's table creation feature. Additionally, it would be possible to introduce an EclipseLink feature that could alter tables in an initial schema based on different metadata.
e.g. A base tenant would have an Employee table with just a name and address field. Another tenant could have an Employee table with a name, address, and employee number field.
Static Fields
Simply define extra fields in each database table that can used to store extra data.
e.g. A table for Employee would contain name, address, attribute1, attribute2 etc...
This table architecture can be used with most of the object model strategies above.
Secondary Tables
EclipseLink supports secondary tables and these could be used to extend object models.
e.g. A base Employee table could contain name and address, a secondary table could contain a foreign key to the base table, and a set of additional field. (e.g. employee number, or attribute1 etc)
Secondary tables could be provided with preset fields in much the same way as the Static Field model above, or secondary tables could be created for each tenant that needed extra data. Dynamic metadata could be provided to change each tenants mapping to access their tables.
Map Table
Attributes are stored in a table that contains a key, an attribute name, and an attribute value. The table could optionally have a foreign key that mapped to a source table.
e.g. Employee table contains an id (and possibly some of the data). Attributes are contained in a table that contains a foreign key to the Employee table, an attribute name and an attribute value.
With this strategy, the map table could contain all the attributes, or the main table could contain some of the attributes and the map table could contain the rest.
Other considerations
- Security
- VPD?
- Co-habitation and selection criteria
- Additional join criteria feature