29

I was looking at docs of spring data, and didn't find a reasons to use methods read...By, get...By instead of find...By (as it usually done). Please clarify:

  • what does this methods do?
  • or what is purpose of this methods is?
  • In what cases better use this methods?
  • what is the difference between them?

Could you write an example of query..By method?

manish
  • 18,840
  • 4
  • 63
  • 89
Михаил Дмитряха
  • 568
  • 1
  • 6
  • 13
  • 5
    There is no difference between these four approaches. These have been provided as options to suit individual preferences as different developers may have different preferences for how they would like to name their accessor methods. `Foo findByName (String name)`, `Foo getByName (String name)`, `Foo queryByName (String name)` and `Foo readByName (String name)` are all equivalent - they will find a `Foo` with a name matching the value passed as the `name` parameter. – manish Oct 05 '16 at 11:44

4 Answers4

42

I don't know how about other subprojects, but for Spring Data JPA (1.10.2) these methods will work as aliases. Each method invocation will generate identical criteria query (and identical SQL query).

Internally there is no distinction between these prefixes. It's used only for query pattern matching:

private static final String QUERY_PATTERN = "find|read|get|query|stream";

https://github.com/spring-projects/spring-data-commons/blob/8bc022ebd7097b921ae1ef6c87f0ae9fc05bba5f/src/main/java/org/springframework/data/repository/query/parser/PartTree.java#L54

The same approach is used for remove...By vs delete...By methods:

private static final String DELETE_PATTERN = "delete|remove";
Maciej Marczuk
  • 3,275
  • 26
  • 23
6

I think this will help you to understand..

The difference between the two interfaces lies in the semantic of their methods. The CRUD repository “finds” something whereas the JPA repository “gets” something. While “find” might lead to no result at all, “get” will always return something – otherwise the JPA repository throws an exception.

source: https://tuhrig.de/find-vs-get/

You can see this post also. https://softwareengineering.stackexchange.com/questions/182113/how-and-why-to-decide-between-naming-methods-with-get-and-find-prefixes

emon
  • 1,241
  • 1
  • 16
  • 16
1

I don't know how Spring implemented this in the past, but at least currently it's not correct that they are the same (just alias).

Spring JPA is layer on top of JPA. Therefore each of these operations is mapped to a Standard JPA operation:

findById(id) -> [on JPA] entityManager.find

Whilst, getOne(id) -> [JPA] entityManager.getReference

So what's the difference on JPA then?

entityManager.find goes direactly to the DB, executes the query and gets the result in memory. Pretty straightforward.

entityManager.getReference is less used (because don't know it). It's sort of a lazy find.
That is, it doesn't go directly to the DB. It only goes when the data is used. Its main target is when you just want a reference to some entity, but you won't use the entity.

For instance:

class Customer {
    Long id;
    ... many other fields
}

class Order {

    Customer customer;
    // ... other
}

You want to save a new Order:

var order = new Order();
// order.setCustomer(repo.findById(123L));  // Opt 1: goes directly to DB and load everything from this customer. But we don't need it all
order.setCustomer(repo.getOne(123L));  // Opt 2: Won't go to DB for the customer
orderRepo.saveOrUpdate(order);

You can check a whole article explaining the diff, and better about getReference here: https://vladmihalcea.com/entitymanager-find-getreference-jpa/

RicardoS
  • 1,955
  • 1
  • 19
  • 22
1

It seems to me that accepted answer is incorrect. It is different internally in both cases:

  • getById() returns a reference to the entity with the given identifier. It invokes EntityManager.getReference() and returns a lazy proxy. So when you are out of transaction with this response - you will get LazyInitializationException when trying to get lazy fields.
  • findById() fetches real object from database.
Zon
  • 16,036
  • 6
  • 82
  • 92