Consideration on Java Persistence Framework 2017 (6) Ebean

Previous post

-Discussion on Java Persistence Framework for 2017 (1) -Consideration of 2017 Java Persistence Framework (2) Doma2 -Guessing about the 2017 Java Persistence Framework (3) Reladomo -Discussion on Java Persistence Framework for 2017 (4) jOOQ -Discussion on Java Persistence Framework for 2017 (5) Iciql

Preface

Since I am writing using the gap time, I would appreciate it if you could point out any parts with poor accuracy. First, exclude those that are EOL. We will consider paid functions, but we will not actually use them, due to the problem of pockets. The DB used is fixed to Postgre for a stupid reason such as "Well, maybe Postgre can be used even if it is not specified."

environment

• PostgreSQL 9.6.3
• Ebean 11.5.1
• Java 64bit 8u144 ――When I set proxy from one end, maven finally worked, I did it

Table structure

Correspondence range

○: Correspondence ×: Not supported

Impressions

--There is no automatic generation of entities. ――The usability is almost JPA implementation, JPA dependent. --However, sessionless, entities may be cached within the transaction range. ――The number of settings is small and the clarity is amazing. -Annotation processing that was also used in Doma2 is used ――But I have only seen it with or without enhancement (* I think it means a compiled code extension) ――I don't feel much benefit.

sample

Single table search

Search all

Main.java

EbeanServer server = Ebean.getServer("example");
server.beginTransaction();
server.find(Employee.class).findList().stream().forEach(e -> {
    System.out.println(e.id + ":" + e.first_name + " " + e.middle_name + " " + e.last_name);
});
server.endTransaction();

Primary key search

Main.java

//Normal guy
server.find(Employee.class).where().eq("id", Long.valueOf(1)).findList().stream().forEach(e -> {
    System.out.println(e.id + ":" + e.first_name + " " + e.middle_name + " " + e.last_name);
});

//Type-safe guy
server.find(Employee.class).where().idEq(Long.valueOf(1)).findList().stream().forEach(e -> {
    System.out.println(e.id + ":" + e.first_name + " " + e.middle_name + " " + e.last_name);
});

//The guy who uses the type safe query bean
new QEmployee().id.eq(Long.valueOf(1)).findList().stream().forEach(e -> {
    System.out.println(e.id + ":" + e.first_name + " " + e.middle_name + " " + e.last_name);
});

Table join

Main.java

server.find(Employee.class).findList().stream().forEach(e -> {
    System.out.format("%1s:%2s %3s %4s\n", e.id, e.first_name, e.middle_name, e.last_name);
    e.posts.stream().forEach(p -> {
        System.out.format("\t%1s: %2s, %3s\n", p.id, p.employee_id, p.name);
    });
});

Employee.java

@Entity
@Table(name="employee")
public class Employee extends Model {
    @Id
    @GeneratedValue(strategy= GenerationType.SEQUENCE)
    public long id;
    public String first_name;
    public String middle_name;
    public String last_name;

    @OneToMany(mappedBy = "employee")
    public List<Post> posts;
}

Post.java

@Entity
@Table(name="post")
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    public long id;
    public long employee_id;
    public String name;

    @ManyToOne(optional=false)
    public Employee employee;
}

The point

--Since it is almost a JPA implementation, it is easy for developers who are accustomed to JPA to use and easy to describe. ――On the other hand, you need to get used to JPA --Since it supports Spring and Play, it is worth considering when using the framework. --The n + 1 problem will also be optimized when issuing SQL, which will be confirmed later.

Addictive points

--When I clean and execute it, I get angry like "Bean class XXXXX is not enhanced?" ――When you look at the head family, it says "Documentation / Setup / Enhanced" ... --Maven plugin put clean, build, enhance, run to solve

After post

Is not yet.

Reference article

• Ebean ORM - Java/Kotlin/JVM -20170708 Ebean Introduction (O / R Mapper Study Group in Big City)