11. Fetching

Fetching, essentially, is the process of grabbing data from the database and making it available to the application. Tuning how an application does fetching is one of the biggest factors in determining how an application will perform. Fetching too much data, in terms of width (values/columns) and/or depth (results/rows), adds unnecessary overhead in terms of both JDBC communication and ResultSet processing. Fetching too little data might cause additional fetching to be needed. Tuning how an application fetches data presents a great opportunity to influence the overall application performance.

11.1. The basics

The concept of fetching breaks down into two different questions.

• When should the data be fetched? Now? Later?

• How should the data be fetched?

There are a number of scopes for defining fetching:

static

Static definition of fetching strategies is done in the mappings. The statically-defined fetch strategies are used in the absence of any dynamically defined strategies.

• SELECT

  Performs a separate SQL select to load the data. This can either be EAGER (the second select is issued immediately) or LAZY (the second select is delayed until the data is needed). This is the strategy generally termed N+1.

  JOIN

  Inherently an EAGER style of fetching. The data to be fetched is obtained through the use of an SQL outer join.

  BATCH

  Performs a separate SQL select to load a number of related data items using an IN-restriction as part of the SQL WHERE-clause based on a batch size. Again, this can either be EAGER (the second select is issued immediately) or LAZY (the second select is delayed until the data is needed).

  SUBSELECT

  Performs a separate SQL select to load associated data based on the SQL restriction used to load the owner. Again, this can either be EAGER (the second select is issued immediately) or LAZY (the second select is delayed until the data is needed).

dynamic (sometimes referred to as runtime)

The dynamic definition is really use-case centric. There are multiple ways to define dynamic fetching:

• fetch profiles

  defined in mappings, but can be enabled/disabled on the Session.

  HQL / JPQL

  both Hibernate and JPA Criteria queries have the ability to specify fetching, specific to said query.

  entity graphs

  starting in Hibernate 4.2 (JPA 2.1), this is also an option.

11.2. Direct fetching vs. entity queries

To see the difference between direct fetching and entity queries in regard to eagerly fetched associations, consider the following entities:

Example 403. Domain model

@Entity(name = "Department")
public static class Department {
    @Id
    private Long id;
    //Getters and setters omitted for brevity
}
@Entity(name = "Employee")
public static class Employee {
    @Id
    private Long id;
    @NaturalId
    private String username;
    @ManyToOne(fetch = FetchType.EAGER)
    private Department department;
    //Getters and setters omitted for brevity
}

The Employee entity has a @ManyToOne association to a Department which is fetched eagerly.

When issuing a direct entity fetch, Hibernate executed the following SQL query:

Example 404. Direct fetching example

Employee employee = entityManager.find( Employee.class, 1L );

select
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.username as username2_1_0_,
    d.id as id1_0_1_
from
    Employee e
left outer join
    Department d
        on e.department_id=d.id
where
    e.id = 1

The LEFT JOIN clause is added to the generated SQL query because this association is required to be fetched eagerly.

On the other hand, if you are using an entity query that does not contain a JOIN FETCH directive to the Department association:

Example 405. Entity query fetching example

Employee employee = entityManager.createQuery(
        "select e " +
        "from Employee e " +
        "where e.id = :id", Employee.class)
.setParameter( "id", 1L )
.getSingleResult();

select
    e.id as id1_1_,
    e.department_id as departme3_1_,
    e.username as username2_1_
from
    Employee e
where
    e.id = 1
select
    d.id as id1_0_0_
from
    Department d
where
    d.id = 1

Hibernate uses a secondary select instead. This is because the entity query fetch policy cannot be overridden, so Hibernate requires a secondary select to ensure that the EAGER association is fetched prior to returning the result to the user.

11.3. Applying fetch strategies

Let’s consider these topics as it relates to a simple domain model and a few use cases.

Example 406. Sample domain model

@Entity(name = "Department")
public static class Department {
    @Id
    private Long id;
    @OneToMany(mappedBy = "department")
    private List<Employee> employees = new ArrayList<>();
    //Getters and setters omitted for brevity
}
@Entity(name = "Employee")
public static class Employee {
    @Id
    private Long id;
    @NaturalId
    private String username;
    @Column(name = "pswd")
    @ColumnTransformer(
        read = "decrypt( 'AES', '00', pswd  )",
        write = "encrypt('AES', '00', ?)"
    )
    private String password;
    private int accessLevel;
    @ManyToOne(fetch = FetchType.LAZY)
    private Department department;
    @ManyToMany(mappedBy = "employees")
    private List<Project> projects = new ArrayList<>();
    //Getters and setters omitted for brevity
}
@Entity(name = "Project")
public class Project {
    @Id
    private Long id;
    @ManyToMany
    private List<Employee> employees = new ArrayList<>();
    //Getters and setters omitted for brevity
}

11.4. No fetching

For the first use case, consider the application login process for an Employee. Let’s assume that login only requires access to the Employee information, not Project nor Department information.

Example 407. No fetching example

Employee employee = entityManager.createQuery(
    "select e " +
    "from Employee e " +
    "where " +
    "    e.username = :username and " +
    "    e.password = :password",
    Employee.class)
.setParameter( "username", username)
.setParameter( "password", password)
.getSingleResult();

In this example, the application gets the Employee data. However, because all associations from Employee are declared as LAZY (JPA defines the default for collections as LAZY) no other data is fetched.

If the login process does not need access to the Employee information specifically, another fetching optimization here would be to limit the width of the query results.

Example 408. No fetching (scalar) example

Integer accessLevel = entityManager.createQuery(
    "select e.accessLevel " +
    "from Employee e " +
    "where " +
    "    e.username = :username and " +
    "    e.password = :password",
    Integer.class)
.setParameter( "username", username)
.setParameter( "password", password)
.getSingleResult();

11.5. Dynamic fetching via queries

For the second use case, consider a screen displaying the Projects for an Employee. Certainly access to the Employee is needed, as is the collection of Projects for that Employee. Information about Departments, other Employees or other Projects is not needed.

Example 409. Dynamic JPQL fetching example

Employee employee = entityManager.createQuery(
    "select e " +
    "from Employee e " +
    "left join fetch e.projects " +
    "where " +
    "    e.username = :username and " +
    "    e.password = :password",
    Employee.class)
.setParameter( "username", username)
.setParameter( "password", password)
.getSingleResult();

Example 410. Dynamic query fetching example

CriteriaBuilder builder = entityManager.getCriteriaBuilder();
CriteriaQuery<Employee> query = builder.createQuery( Employee.class );
Root<Employee> root = query.from( Employee.class );
root.fetch( "projects", JoinType.LEFT);
query.select(root).where(
    builder.and(
        builder.equal(root.get("username"), username),
        builder.equal(root.get("password"), password)
    )
);
Employee employee = entityManager.createQuery( query ).getSingleResult();

In this example we have an Employee and their Projects loaded in a single query shown both as an HQL query and a JPA Criteria query. In both cases, this resolves to exactly one database query to get all that information.

11.6. Dynamic fetching via JPA entity graph

JPA 2.1 introduced entity graph so the application developer has more control over fetch plans. It has two modes to choose from:

fetch graph

In this case, all attributes specified in the entity graph will be treated as FetchType.EAGER, and all attributes not specified will ALWAYS be treated as FetchType.LAZY.

load graph

In this case, all attributes specified in the entity graph will be treated as FetchType.EAGER, but attributes not specified use their static mapping specification.

Below is an fetch graph dynamic fetching example:

Example 411. Fetch graph example

@Entity(name = "Employee")
@NamedEntityGraph(name = "employee.projects",
    attributeNodes = @NamedAttributeNode("projects")
)

Employee employee = entityManager.find(
    Employee.class,
    userId,
    Collections.singletonMap(
        "javax.persistence.fetchgraph",
        entityManager.getEntityGraph( "employee.projects" )
    )
);

An EntityGraph is the root of a “load plan” and must correspond to an EntityType.

11.6.1. JPA (key) subgraphs

A sub-graph is used to control the fetching of sub-attributes of the AttributeNode it is applied to. It is generally defined via the @NamedSubgraph annotation.

If we have a Project parent entity which has an employees child associations, and we’d like to fetch the department for the Employee child association.

Example 412. Fetch graph with a subgraph mapping

@Entity(name = "Project")
@NamedEntityGraph(name = "project.employees",
    attributeNodes = @NamedAttributeNode(
        value = "employees",
        subgraph = "project.employees.department"
    ),
    subgraphs = @NamedSubgraph(
        name = "project.employees.department",
        attributeNodes = @NamedAttributeNode( "department" )
    )
)
public static class Project {
    @Id
    private Long id;
    @ManyToMany
    private List<Employee> employees = new ArrayList<>();
    //Getters and setters omitted for brevity
}

When fetching this entity graph, Hibernate generates the following SQL query:

Example 413. Fetch graph with a subgraph mapping

Project project = doInJPA( this::entityManagerFactory, entityManager -> {
    return entityManager.find(
        Project.class,
        1L,
        Collections.singletonMap(
            "javax.persistence.fetchgraph",
            entityManager.getEntityGraph( "project.employees" )
        )
    );
} );

select
    p.id as id1_2_0_, e.id as id1_1_1_, d.id as id1_0_2_,
    e.accessLevel as accessLe2_1_1_,
    e.department_id as departme5_1_1_,
    decrypt( 'AES', '00', e.pswd  ) as pswd3_1_1_,
    e.username as username4_1_1_,
    p_e.projects_id as projects1_3_0__,
    p_e.employees_id as employee2_3_0__
from
    Project p
inner join
    Project_Employee p_e
        on p.id=p_e.projects_id
inner join
    Employee e
        on p_e.employees_id=e.id
inner join
    Department d
        on e.department_id=d.id
where
    p.id = ?
-- binding parameter [1] as [BIGINT] - [1]

Specifying a sub-graph is only valid for an attribute (or its “key”) whose type is a ManagedType. So while an EntityGraph must correspond to an EntityType, a Subgraph is legal for any ManagedType. An attribute’s key is defined as either:

• For a singular attribute, the attribute’s type must be an IdentifiableType and that IdentifiableType must have a composite identifier. The “key sub-graph” is applied to the identifier type. The non-key sub-graph applies to the attribute’s value, which must be a ManagedType.

• For a plural attribute, the attribute must be a Map and the Map’s key value must be a ManagedType. The “key sub-graph” is applied to the Map’s key type. In this case, the non-key sub-graph applies to the plural attribute’s value/element.

11.6.2. JPA SubGraph sub-typing

SubGraphs can also be sub-type specific. Given an attribute whose value is an inheritance hierarchy, we can refer to attributes of a specific sub-type using the forms of sub-graph definition that accept the sub-type Class.

11.6.3. Creating and applying JPA graphs from text representations

Hibernate allows the creation of JPA fetch/load graphs by parsing a textual representation of the graph. Generally speaking, the textual representation of a graph is a comma-separated list of attribute names, optionally including any sub-graph specifications. org.hibernate.graph.EntityGraphParser is the starting point for such parsing operations.

Example 414. Parsing a simple graph

final EntityGraph<Project> graph = GraphParser.parse(
        Project.class,
        "employees( department )",
        entityManager
);

This example actually functions exactly as Fetch graph with a subgraph mapping, just using a parsed graph rather than a named graph.

The syntax also supports defining “key sub-graphs”. To specify a key sub-graph, .key is added to the end of the attribute name.

Example 415. Parsing an entity key graph

final EntityGraph<Movie> graph = GraphParser.parse(
        Movie.class,
        "cast.key( name )",
        entityManager
);

Example 416. Parsing a map key graph

final EntityGraph<Ticket> graph = GraphParser.parse(
        Ticket.class,
        "showing.key( movie( cast ) )",
        entityManager
);

Parsing can also handle sub-type specific sub-graphs. For example, given an entity hierarchy of LegalEntity ← (Corporation | Person | NonProfit) and an attribute named responsibleParty whose type is the LegalEntity base type we might have:

responsibleParty(Corporation: ceo)

We can even duplicate the attribute names to apply different sub-type sub-graphs:

responsibleParty(taxIdNumber), responsibleParty(Corporation: ceo), responsibleParty(NonProfit: sector)

The duplicated attribute names are handled according to the JPA specification which says that duplicate specification of the attribute node results in the originally registered AttributeNode to be re-used effectively merging the 2 AttributeNode specifications together. In other words, the above specification creates a single AttributeNode with 3 distinct SubGraphs. It is functionally the same as calling:

Class<Invoice> invoiceClass = ...;
javax.persistence.EntityGraph<Invoice> invoiceGraph = entityManager.createEntityGraph( invoiceClass );
invoiceGraph.addAttributeNode( "responsibleParty" );
invoiceGraph.addSubgraph( "responsibleParty" ).addAttributeNode( "taxIdNumber" );
invoiceGraph.addSubgraph( "responsibleParty", Corporation.class ).addAttributeNode( "ceo" );
invoiceGraph.addSubgraph( "responsibleParty", NonProfit.class ).addAttributeNode( "sector" );

11.6.4. Combining multiple JPA entity graphs into one

Multiple entity graphs can be combined into a single “super graph” that acts as a union. Graph from the previous example can also be built by combining separate aspect graphs into one, such as:

Example 417. Combining multiple graphs into one

final EntityGraph<Project> a = GraphParser.parse(
        Project.class, "employees( username )", entityManager
);
final EntityGraph<Project> b = GraphParser.parse(
        Project.class, "employees( password, accessLevel )", entityManager
);
final EntityGraph<Project> c = GraphParser.parse(
        Project.class, "employees( department( employees( username ) ) )", entityManager
);
final EntityGraph<Project> all = EntityGraphs.merge( entityManager, Project.class, a, b, c );

11.7. Dynamic fetching via Hibernate profiles

Suppose we wanted to leverage loading by natural-id to obtain the Employee information in the “projects for and employee” use-case. Loading by natural-id uses the statically defined fetching strategies, but does not expose a means to define load-specific fetching. So we would leverage a fetch profile.

Example 418. Fetch profile example

@Entity(name = "Employee")
@FetchProfile(
    name = "employee.projects",
    fetchOverrides = {
        @FetchProfile.FetchOverride(
            entity = Employee.class,
            association = "projects",
            mode = FetchMode.JOIN
        )
    }
)

session.enableFetchProfile( "employee.projects" );
Employee employee = session.bySimpleNaturalId( Employee.class ).load( username );

Here the Employee is obtained by natural-id lookup and the Employee’s Project data is fetched eagerly. If the Employee data is resolved from cache, the Project data is resolved on its own. However, if the Employee data is not resolved in cache, the Employee and Project data is resolved in one SQL query via join as we saw above.

11.8. Batch fetching

Hibernate offers the @BatchSize annotation, which can be used when fetching uninitialized entity proxies.

Considering the following entity mapping:

Example 419. @BatchSize mapping example

@Entity(name = "Department")
public static class Department {
    @Id
    private Long id;
    @OneToMany(mappedBy = "department")
    //@BatchSize(size = 5)
    private List<Employee> employees = new ArrayList<>();
    //Getters and setters omitted for brevity
}
@Entity(name = "Employee")
public static class Employee {
    @Id
    private Long id;
    @NaturalId
    private String name;
    @ManyToOne(fetch = FetchType.LAZY)
    private Department department;
    //Getters and setters omitted for brevity
}

Considering that we have previously fetched several Department entities, and now we need to initialize the employees entity collection for each particular Department, the @BatchSize annotations allows us to load multiple Employee entities in a single database roundtrip.

Example 420. @BatchSize fetching example

List<Department> departments = entityManager.createQuery(
    "select d " +
    "from Department d " +
    "inner join d.employees e " +
    "where e.name like 'John%'", Department.class)
.getResultList();
for ( Department department : departments ) {
    log.infof(
        "Department %d has {} employees",
        department.getId(),
        department.getEmployees().size()
    );
}

SELECT
    d.id as id1_0_
FROM
    Department d
INNER JOIN
    Employee employees1_
    ON d.id=employees1_.department_id
SELECT
    e.department_id as departme3_1_1_,
    e.id as id1_1_1_,
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.name as name2_1_0_
FROM
    Employee e
WHERE
    e.department_id IN (
        0, 2, 3, 4, 5
    )
SELECT
    e.department_id as departme3_1_1_,
    e.id as id1_1_1_,
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.name as name2_1_0_
FROM
    Employee e
WHERE
    e.department_id IN (
        6, 7, 8, 9, 1
    )

As you can see in the example above, there are only two SQL statements used to fetch the Employee entities associated with multiple Department entities.

11.9. The @Fetch annotation mapping

Besides the FetchType.LAZY or FetchType.EAGER JPA annotations, you can also use the Hibernate-specific @Fetch annotation that accepts one of the following FetchModes:

SELECT

The association is going to be fetched lazily using a secondary select for each individual entity, collection, or join load. It’s equivalent to JPA FetchType.LAZY fetching strategy.

JOIN

Use an outer join to load the related entities, collections or joins when using direct fetching. It’s equivalent to JPA FetchType.EAGER fetching strategy.

SUBSELECT

Available for collections only. When accessing a non-initialized collection, this fetch mode will trigger loading all elements of all collections of the same role for all owners associated with the persistence context using a single secondary select.

11.10. FetchMode.SELECT

To demonstrate how FetchMode.SELECT works, consider the following entity mapping:

Example 421. FetchMode.SELECT mapping example

@Entity(name = "Department")
public static class Department {
    @Id
    private Long id;
    @OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
    @Fetch(FetchMode.SELECT)
    private List<Employee> employees = new ArrayList<>();
    //Getters and setters omitted for brevity
}
@Entity(name = "Employee")
public static class Employee {
    @Id
    @GeneratedValue
    private Long id;
    @NaturalId
    private String username;
    @ManyToOne(fetch = FetchType.LAZY)
    private Department department;
    //Getters and setters omitted for brevity
}

Considering there are multiple Department entities, each one having multiple Employee entities, when executing the following test case, Hibernate fetches every uninitialized Employee collection using a secondary SELECT statement upon accessing the child collection for the first time:

Example 422. FetchMode.SELECT mapping example

List<Department> departments = entityManager.createQuery(
    "select d from Department d", Department.class )
.getResultList();
log.infof( "Fetched %d Departments", departments.size());
for (Department department : departments ) {
    assertEquals( 3, department.getEmployees().size() );
}

SELECT
    d.id as id1_0_
FROM
    Department d
-- Fetched 2 Departments
SELECT
    e.department_id as departme3_1_0_,
    e.id as id1_1_0_,
    e.id as id1_1_1_,
    e.department_id as departme3_1_1_,
    e.username as username2_1_1_
FROM
    Employee e
WHERE
    e.department_id = 1
SELECT
    e.department_id as departme3_1_0_,
    e.id as id1_1_0_,
    e.id as id1_1_1_,
    e.department_id as departme3_1_1_,
    e.username as username2_1_1_
FROM
    Employee e
WHERE
    e.department_id = 2

The more Department entities are fetched by the first query, the more secondary SELECT statements are executed to initialize the employees collections. Therefore, FetchMode.SELECT can lead to N+1 query issues.

11.11. FetchMode.SUBSELECT

To demonstrate how FetchMode.SUBSELECT works, we are going to modify the FetchMode.SELECT mapping example to use FetchMode.SUBSELECT:

Example 423. FetchMode.SUBSELECT mapping example

@OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
@Fetch(FetchMode.SUBSELECT)
private List<Employee> employees = new ArrayList<>();

Now, we are going to fetch all Department entities that match a given filtering predicate and then navigate their employees collections.

Hibernate is going to avoid the N+1 query issue by generating a single SQL statement to initialize all employees collections for all Department entities that were previously fetched. Instead of using passing all entity identifiers, Hibernate simply reruns the previous query that fetched the Department entities.

Example 424. FetchMode.SUBSELECT mapping example

List<Department> departments = entityManager.createQuery(
    "select d " +
    "from Department d " +
    "where d.name like :token", Department.class )
.setParameter( "token", "Department%" )
.getResultList();
log.infof( "Fetched %d Departments", departments.size());
for (Department department : departments ) {
    assertEquals( 3, department.getEmployees().size() );
}

SELECT
    d.id as id1_0_
FROM
    Department d
where
    d.name like 'Department%'
-- Fetched 2 Departments
SELECT
    e.department_id as departme3_1_1_,
    e.id as id1_1_1_,
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.username as username2_1_0_
FROM
    Employee e
WHERE
    e.department_id in (
        SELECT
            fetchmodes0_.id
        FROM
            Department fetchmodes0_
        WHERE
            d.name like 'Department%'
    )

11.12. FetchMode.JOIN

To demonstrate how FetchMode.JOIN works, we are going to modify the FetchMode.SELECT mapping example to use FetchMode.JOIN instead:

Example 425. FetchMode.JOIN mapping example

@OneToMany(mappedBy = "department")
@Fetch(FetchMode.JOIN)
private List<Employee> employees = new ArrayList<>();

Now, we are going to fetch one Department and navigate its employees collections.

Hibernate is going to avoid the secondary query by issuing an OUTER JOIN for the employees collection.

Example 426. FetchMode.JOIN mapping example

Department department = entityManager.find( Department.class, 1L );
log.infof( "Fetched department: %s", department.getId());
assertEquals( 3, department.getEmployees().size() );

SELECT
    d.id as id1_0_0_,
    e.department_id as departme3_1_1_,
    e.id as id1_1_1_,
    e.id as id1_1_2_,
    e.department_id as departme3_1_2_,
    e.username as username2_1_2_
FROM
    Department d
LEFT OUTER JOIN
    Employee e
        on d.id = e.department_id
WHERE
    d.id = 1
-- Fetched department: 1

This time, there was no secondary query because the child collection was loaded along with the parent entity.

11.13. @LazyCollection

The @LazyCollection annotation is used to specify the lazy fetching behavior of a given collection. The possible values are given by the [LazyCollectionOption](https://docs.jboss.org/hibernate/orm/5.4/javadocs/org/hibernate/annotations/LazyCollectionOption.html) enumeration:

TRUE

Load it when the state is requested.

FALSE

Eagerly load it.

EXTRA

Prefer extra queries over full collection loading.

The TRUE and FALSE values are deprecated since you should be using the JPA FetchType attribute of the @ElementCollection, @OneToMany, or @ManyToMany collection.

The EXTRA value has no equivalent in the JPA specification, and it’s used to avoid loading the entire collection even when the collection is accessed for the first time. Each element is fetched individually using a secondary query.

Example 427. LazyCollectionOption.EXTRA mapping example

@Entity(name = "Department")
public static class Department {
    @Id
    private Long id;
    @OneToMany(mappedBy = "department", cascade = CascadeType.ALL)
    @OrderColumn(name = "order_id")
    @LazyCollection( LazyCollectionOption.EXTRA )
    private List<Employee> employees = new ArrayList<>();
    //Getters and setters omitted for brevity
}
@Entity(name = "Employee")
public static class Employee {
    @Id
    private Long id;
    @NaturalId
    private String username;
    @ManyToOne(fetch = FetchType.LAZY)
    private Department department;
    //Getters and setters omitted for brevity
}

Now, considering we have the following entities:

Example 428. LazyCollectionOption.EXTRA Domain Model example

Department department = new Department();
department.setId( 1L );
entityManager.persist( department );
for (long i = 1; i <= 3; i++ ) {
    Employee employee = new Employee();
    employee.setId( i );
    employee.setUsername( String.format( "user_%d", i ) );
    department.addEmployee(employee);
}

When fetching the employee collection entries by their position in the List, Hibernate generates the following SQL statements:

Example 429. LazyCollectionOption.EXTRA fetching example

Department department = entityManager.find(Department.class, 1L);
int employeeCount = department.getEmployees().size();
for(int i = 0; i < employeeCount; i++ ) {
    log.infof( "Fetched employee: %s", department.getEmployees().get( i ).getUsername());
}

SELECT
    max(order_id) + 1
FROM
    Employee
WHERE
    department_id = ?
-- binding parameter [1] as [BIGINT] - [1]
SELECT
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.username as username2_1_0_
FROM
    Employee e
WHERE
    e.department_id=?
    AND e.order_id=?
-- binding parameter [1] as [BIGINT]  - [1]
-- binding parameter [2] as [INTEGER] - [0]
SELECT
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.username as username2_1_0_
FROM
    Employee e
WHERE
    e.department_id=?
    AND e.order_id=?
-- binding parameter [1] as [BIGINT]  - [1]
-- binding parameter [2] as [INTEGER] - [1]
SELECT
    e.id as id1_1_0_,
    e.department_id as departme3_1_0_,
    e.username as username2_1_0_
FROM
    Employee e
WHERE
    e.department_id=?
    AND e.order_id=?
-- binding parameter [1] as [BIGINT]  - [1]
-- binding parameter [2] as [INTEGER] - [2]