Ebean ORM for Java

Fast data access and even faster coding

Version 4.1.5

Uses JPA Mapping

Use JPA Mapping annotations.

public class Customer extends BaseModel {

  String name;

  Address billingAddress;

  @OneToMany(mappedBy="customer", cascade=CascadeType.PERSIST)
  List<Contact> contacts;

Simple to save, delete

With Ebean it is very easy to insert, update, delete. There is no 'Session' or EntityManager to manage, no merge/flush etc.

  final EbeanServer ebeanServer;

  public void createCustomer(String name) {

    Customer customer = new Customer();


Partial Objects

Just fetch what you need. Makes is it easy to optimise the query and get the SQL that you want.

Customer customer = ebeanServer.find(Customer.class)
    .select("name, email")
select t0.id c0, t0.name c1, t0.email c2
  from customer t0
 where t0.id = ?

Query language

Ebean automatically adds the appropriate joins to support the queries fetch, where and order by clauses. This makes it easy to

List<Customer> customers = ebeanServer.find(Customer.class)
    // join added for this predicate automatically
    .where().eq("billingAddress.country.code", "NZ")
select t0.id c0, t0.name c1
  from customer t0
  left outer join o_address t1 on t1.id = t0.billing_address_id
 where t1.country_code = ?


Ebean has an taken a different architectural when compared with JPA and JDO and this has important implications. Specifically Ebean does not use a 'Persistence Context' or 'Session' when it persists objects back to the database. This means you don't need to attach/detach your beans or manage a JPA EntityManager or JDO PersistenceManager.

Persisting a bean means you just call save(). Cascade persistence is supported by traversing the relationships on the bean. It is easy to use and

Partial Objects

Partial objects are very important for a high performance ORM and Ebean has this as the bases of its design. The query language makes it trivial to fetch only the properties you want and partial objects are supported through-out. JPA FetchGroups are trying to do the same task but look like a last minute add-on - partial object support needs to be part of the query language for a high performance ORM.

Query Language Design

The Ebean query language was designed to make is easier to use. The developer specifies the parts of the object graph they want to fetch, the predicates and the order by and then Ebean figures out all the underlying joins that are required and if the joins need to be inner or outer joins. This makes is much easier for the developer to use.

Interesting Features

  • Raw SQL: Using raw sql is easy and the bean returned are fully featured with the expected lazy loading and persisting support because sometimes you need full control
  • Paging results: Use findRowCount() or findPagedList() to make handling paged results easy.
  • Large Query Support: Use findIterate() to process lots of objects without having them all in memory. Typically for batch processing requirements.
  • Batch inserting: Ability to tune batch inserting with per-transaction control over JDBC batch size and the ability to turn off getGeneratedKeys and Cascade persist.
  • DB Encryption: Use DB encryption transparently with @Encrypt.
  • JSON support: Built in JSON support. Marshalling/unmarshalling is fully aware of circular relationships, inheritance, partial objects and all data types.
  • Automatic Query Tuning: Has 'Autofetch' automatic query tuning support. Queries can be automatically optimised based on profiling the object graph use.
  • Stateless Updates: Populate a bean object graph and then update() it without querying it from the DB. This is useful to support REST.
  • Bulk Updates/Deletes: Use bulk update statements as you desire because sometimes a more 'relational' approach is vastly more efficient - Ebean is happy with that and the L2 cache will invalidate the appropriate cache regions where necessary.