Skip to main content

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.

Jump to: navigation, search

EclipseLink/Development/Indigo/Multi-Tenancy

Bug ??????

Multi-Tenancy

The goal of this feature is to allow multiple tenants on the same database schema using a tenant id column.

Requirements

Configuration

The tenant id field and a tenant id value will be configured through EclipseLink properties within the persistence.xml file.

  • eclipselink.multi-tenant.id
  • eclipselink.multi-tenant.id-column

When a multi-tenant id is specified, the multi-tenant column will default to "TENANT_ID" if it is not specified by the user. That column is then expected to be available from the following tables of the schema:

  1. @Table
  2. @SecondaryTable

It is not expected for the following tables:

  1. @CollectionTable
  2. @JoinTable

When using DDL generation, the user need not worry about this. The DDL generation framework will be responsible for ensuring all necessary tables have a tenant id column.

Core

The tenant id and tenant id column will be applied in two places.

  1. We will leverage the current additional join expression from the DescriptorQueryManager to filter tenants. This is similar to the Additional Criteria feature.
  2. For inserts, we will append the tenant id column and value when building the row representation of an object. This is done in the following methods from ObjectBuilder (Note: similar thing is done for the the handling of the discriminiator column within an inheritance hierarchy)
    1. buildRow
    2. buildRowForShallowInsert
    3. buildRowForUpdate
    4. buildRowWithChangeSet
    5. buildTemplateInsertRow

Querying

The tenant id column and value will be supported through the following entity manager operations:

  • persist
  • find
  • refresh

And the following queries:

  • named queries

NOTE: EclipseLink will not modify, therefore, support multi-tenancy through named native queries. When using these types of queries within a multi-tenant environment, the user will need to be aware and handle any multi-tenancy issues themselves directly in their native query. To all intent and purpose, named native queries should be avoided in a multi-tenant environment.

DDL generation

DDL generation will need to support the generation of tenant id columns.

Back to the top