Difference between revisions of "EclipseLink/UserGuide/JPA/Basic JPA Development/Mapping/Additional Criteria"

From Eclipsepedia

Jump to: navigation, search
m
m
Line 78: Line 78:
  
 
In a multitenancy environment, tenants (users, clients, organizations, applications) can share database tables, but the views on the data are restricted so that tenants have access only to their own data. You can use additional criteria to configure such restrictions.   
 
In a multitenancy environment, tenants (users, clients, organizations, applications) can share database tables, but the views on the data are restricted so that tenants have access only to their own data. You can use additional criteria to configure such restrictions.   
 +
 +
=====Multitenancy Example 1 =====
  
 
The following example restricts the data for a “Billing” client, such as a billing application or billing organization:  
 
The following example restricts the data for a “Billing” client, such as a billing application or billing organization:  
Line 83: Line 85:
 
@AdditionalCriteria("TENANT = 'Billing'")
 
@AdditionalCriteria("TENANT = 'Billing'")
 
</source>
 
</source>
 +
 +
=====Multitenancy Example 2 =====
  
 
The following example could be used in an application that can be used by multiple tenants at the same time. The additional criteria is defined as follows:
 
The following example could be used in an application that can be used by multiple tenants at the same time. The additional criteria is defined as follows:

Revision as of 12:56, 19 May 2011

EclipseLink JPA

link="http://wiki.eclipse.org/EclipseLink"
EclipseLink
Website
Download
Community
Mailing ListForumsIRC
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse Source


@AdditionalCriteria

Use @AdditionalCriteria to define parameterized views on data. You can define additional criteria on entities or mapped superclasses. When specified at the mapped superclass level, the additional criteria definition applies to all inheriting entities, unless those entities define their own additional criteria, in which case those defined for the mapped superclass are ignored.

Additional criteria can provide an additional filtering mechanism for queries. This filtering option, for example, allows you to use an existing additional JOIN expression defined for the entity or mapped superclass and allows you to pass parameters to it.

@AdditionalCriteria Attributes
Attribute Description Default Required?
value The JPQL fragment to use as the additional criteria. n/a Yes


Defining Additional Criteria

Set additional criteria parameters through properties on the entity manager factory or on the entity manager. When set on the entity manager, you must set the properties before executing a query. Do not change the properties for the lifespan of that entity manager. Properties set on the entity manager override identically named properties set on the entity manager factory.

Additional criteria are not supported with native queries.

Specify additional criteria using the @AdditionalCriteria annotation or the <additional-criteria> element. The additional criteria definition supports any valid JPQL string and must use this as an alias to form the additional criteria. For example,

@AdditionalCriteria("this.address.city IS NOT NULL")

The following example shows additional criteria defined for the entity Employee and then shows the parameters for the additional criteria set on the entity manager.

Define additional criteria on Employee, as follows,...

package model;
 
@AdditionalCriteria("this.company=:COMPANY")
public class Employee {
  ...
}

...then set the property on the EntityManager. This example returns all employees of MyCompany.

entityManager.setProperty("COMPANY", "MyCompany");


The following example shows the <additional-criteria> element used in the eclipselink-orm.xml descriptor:

Example: additional-criteria Element
<additional-criteria>
  <criteria>this.address.city IS NOT NULL</criteria>
</additional-criteria&>

Uses for Additional Criteria

Uses for additional criteria include:

Multitenancy Example

In a multitenancy environment, tenants (users, clients, organizations, applications) can share database tables, but the views on the data are restricted so that tenants have access only to their own data. You can use additional criteria to configure such restrictions.

Multitenancy Example 1

The following example restricts the data for a “Billing” client, such as a billing application or billing organization:

@AdditionalCriteria("TENANT = 'Billing'")
Multitenancy Example 2

The following example could be used in an application that can be used by multiple tenants at the same time. The additional criteria is defined as follows:

@AdditionalCriteria("this.tenant = :tenant")

When the tenant acquires its EntityManagerFactory or EntityManager the persistence/entity manager property tenant is set to the name of the tenant acquring it. For example,

Map properties = new HashMap();
properties.put("tenant", "ACME");
EntityManagerFactory emf = Persistence.createEntityManagerFactory(properties);

or

Map properties = new HashMap();
properties.put("tenant", "ACME");
EntityManager em = factory.createEntityManager(properties);

Soft Delete Example

A soft delete is when data is marked as deleted, but it is not actually deleted from the database. This can be useful for keeping a record of deleted data. The following example filters deleted data from a query:

@AdditionalCriteria("this.isDeleted = false")

Data History Example

History is when a row of data is never removed or updated. On an update, a new row is inserted with a new start and end time instead.

The following example returns the current data from any query, thus filtering out any out-of-date data, for example data stored in a history table.

@AdditionalCriteria("this.endDate is null")

The following example filters on a specific date:

@AdditionalCriteria("this.startDate <= :viewDate and this.endDate >= :viewDate")

Note: EclipseLink also provides specific history support, via HistoryPolicy . See Tracking Changes Using History Policy.

Shared Table Example

For a shared table, there may be inheritance in the table but not in the object model. For example, a SavingsAccount class may be mapped to an ACCOUNT table, but the ACCOUNT table contains both savings account data (SAVINGS) and checking account (CHECKING) data. The following example filters the checking data.


Eclipselink-logo.gif
Version: 2.2.0 DRAFT
Other versions...