Context enabled JPA 2.1 @EntityGraph [DATAJPA-749]

[spring-projects-issues]

Bartłomiej Mocior opened DATAJPA-749 and commented

Currently It's impossible to enable EntityGraph configuration outside of spring data jpa repository. The only possibility is to use @EntityGraph annotation over query method.

for example

@EntityGraph("summary")
Optional<Customer> findByEmailAddress(EmailAddress emailAddress);

Now, it's impossible to reuse this method in different contexts where different entity graph aka fetch profile is required.

Example I have entity Customer with 2 relations: Invoices and Addresses (OneToMany)

• In context 1, let's say 'Displaying Customer data with invoices list' I would like to fetch Customer + invoices only.
• In context 2, let's say 'Displaying Customer data with Addresses' I would like to fetch Customer + addresses only.

Now, with spring data jpa, I have to create another (second) method and annotate it with another "context" @EntityGraph.
What is more, my method's name should generate the same JQL Query, but must have different signature (because it's in the same repository), so I will end up with @Query annotation and code duplication.

The current implementation don't allow to set QueryHints directly on Query - it's possible to annotate method with @QueryHint but it won't solve the problem because it's AFAIK static, and doesn't use SpEL.

Jpa21Utils with tryGetFetchGraphHints get's the query hints from annotation only, maybe it would be good idea if it could additionally take from other source ? Maybe ThreadLocale or any context object ?
Maybe, It would be consistent with spring data API if we could provide EntityGraphContext object to have full controll of execution ?

Proposed solution I "EntityGraphContext"- repository example

interface SomeRepository ... 
Optional<Customer> findByEmailAddress(EmailAddress emailAddress, EntityGraphContext graphCtx);

Client code:

EntityGraphContext graphCtx = EntityGraphContext.enable("summary").withType(EntityGraphType.FETCH);
Optonal<Customer> customer = someRepository.findByEmailAddress(address, graphCtx);

Proposed solution II "EntityGraphThreadLocalContext"- repository example

interface SomeRepository ... 
Optional<Customer> findByEmailAddress(EmailAddress emailAddress);

Client code:

EntityGraphThreadLocalContext.enable("summary").withType(EntityGraphType.FETCH);
Optonal<Customer> customer = someRepository.findByEmailAddress(address);

---

Affects: 1.9 M1 (Gosling)

13 votes, 17 watchers

[spring-projects-issues]

Ryan Rupp commented

This would be a nice feature, I was looking for something like this to support a REST API that allows dynamic response expansion e.g.:

GET /api/customers?expand=address

where the goal would be that all relations are lazy fetched by default and then toggling eager fetch with dynamically built entity graphs based on the expand parameter then we're only traversing the entity as far as the client has actually requested.

As for an explicit parameter vs thread local I think an explicit parameter would be preferable however I can see this would be painful with all the different permutations of parameters available and that basically any method that returns an entity would benefit from being able to programmatically specify the EntityGraph. So, in that regard the thread local approach would be less intrusive at least

[spring-projects-issues]

Réda Housni Alaoui commented

Hello,

I am very interested in this functionality.
I am ready to start working on it.

I think the argument way is preferable even if it is more intrusive.
Since the javax.persistence EntityGraph can only be generated by the EntityManager, I think this argument class will be fully specific to Spring Data JPA. It would be a class holding the EntityGraph name or the EntityGraph modelisation.

Can I have the opinion of some Spring Data JPA maintainers before I start?

Regards

[spring-projects-issues]

Réda Housni Alaoui commented

Could we use JpaEntityGraph to type this new argument?

[spring-projects-issues]

Oliver Drotbohm commented

I am not really keen to add this as it moves store specific knowledge into repository clients. Why would a service have to know about what entity graph is in the first place. The other aspect is that with the projection support for repository methods, there already is a way to define different views that can be returned for the same query.

So very little chance that this will ever make it into the codebase

[spring-projects-issues]

Réda Housni Alaoui commented

Hello Oliver,

Why would a service have to know about what entity graph is in the first place.

Because only the service knows the requested depth. And the service should know that if he wants A.B over many A's with B lazy loaded, that would cause performance issue.

The other aspect is that with the projection support for repository methods, there already is a way to define different views that can be returned for the same query.

• You can't save back the result of a projection directly.
• Building an interface for each combination is very heavy. It looks like what Jackson did with http://wiki.fasterxml.com/JacksonJsonViews. It was not sufficient, so they also provide http://wiki.fasterxml.com/JacksonFeatureJsonFilter which is fully dynamic.
• You can't build your selection dynamically. Projection must be defined at compilation time.
• I think that using projection bypass Hibernate entity level 1 and 2 cache. I didn't verify this point but it seems logical to me. Or are you building an entity graph behind each projection interface?

[spring-projects-issues]

Réda Housni Alaoui commented

• And it seems that you can't use projection on standard repository methods

[spring-projects-issues]

Réda Housni Alaoui commented

I want to add that we also use EntityGraph to select which sub entities will be serialized to the browser.
Thanks to Jackson Hibernate Module, only loaded entities are serialized, lazy unloaded ones are ignored.
In some cases, the browser can make requests using the graph of its choice without having to modify the server side

[spring-projects-issues]

Oliver Drotbohm commented

Because only the service knows the requested depth. And the service should know that if he wants A.B over many A's with B lazy loaded, that would cause performance issue.

To be more precise. The repository client of course has to know what it wants to read. What I am saying though is that must not know about the implementation details. The entity graph is a JPA specific concept, a very poorly designed one beyond that.

You can't save back the result of a projection directly.

Mixing the aspects of persisting object and optimizing on what's read is a bad idea in the first place as it means you compromise the two. I'd argue you want to design your entities to form proper aggregates to express clear consistency boundaries and then those either just fit the read model and you can live with the slight performance decrease as the benefit of being able to just use the type as is outweighs that cost. If your read model diverges from the entity I'd rather tweak my queries to return tailored types in the first place rather than messing with the entities themselves.

Building an interface for each combination is very heavy. It looks like what Jackson did with http://wiki.fasterxml.com/JacksonJsonViews. It was not sufficient, so they also provide http://wiki.fasterxml.com/JacksonFeatureJsonFilter which is fully dynamic.

I fail to see how JSON Views play into this as we're not talking about the rendering here but what data to read in the first place. I personally consider JSON views a very poor solution, too. The look sort of bearable if you only have one. But they become quite some annotation madness once you have a couple of more of them. Also, I think them having to be expressed at the entity in the first place is fundamentally subverting the point. You don't want the entity to know about different views. or be polluted with a plethora of view specific annotations. Externalizing that information using an interface was a deliberate design choice here. Also, using interfaces has the benefit of composability though (multiple) inheritance.

You can't build your selection dynamically. Projection must be defined at compilation time.

Right.I'd argue that if you give clients too much control about what needs to be fetched, you dramatically degrade the abstraction level a repository provides. You're basically turning the repository into a low leave data access API again. If you really need that flexibility, then hide that inside the repository, don't put it in front of it.

As you mention exposing that functionality via REST, too, let me share some thoughts why that idea might be a not so great one as it appears at first glance. You dramatically increase in the API surface as you basically create endlessly more resources (one per each permutation of properties a client can request to be loaded). This dramatically decreases the server's ability to actually cache the representations. In a lot of scenarios I've seen in that regard the overall system architecture was better off providing less flexible HTTP resources as that caused the clients to hit proxy caches more often so that requests don't even hit the application anymore. So producing more coarse grained results will actually pay off.

I think that using projection bypass Hibernate entity level 1 and 2 cache. I didn't verify this point but it seems logical to me. Or are you building an entity graph behind each projection interface?

Whether caches are hit is determined by the queries executed. I don't see why a query result returning a tuple or DTO should be less cacheable than queries returning entities. Quite to the contrary: the projections or DTOs are usually immutable values which makes them much better candidates for caching in the first place. JPA entities are usually way harder to cache as the need to be mutable.

And it seems that you can't use projection on standard repository methods

You'd need to replace findOne(…) or findAll(…) by semantically equivalent query methods but that's not a problem at all

[spring-projects-issues]

Réda Housni Alaoui commented

Whether caches are hit is determined by the queries executed. I don't see why a query result returning a tuple or DTO should be less cacheable than queries returning entities. Quite to the contrary: the projections or DTOs are usually immutable values which makes them much better candidates for caching in the first place. JPA entities are usually way harder to cache as the need to be mutable.

I just performed a test on hibernate first level cache:

@Entity
public class FakeEntity extends StdEntity {
	private String name;
	private String lastName;
}

public interface NoLastName {
    int getId();
    String getName();
}

public interface FakeRepository extends CosCrudRepository<FakeEntity, Integer> {
	NoLastName findById(int id);
}

@Transactional
    @Test
    public void test(){
        FakeEntity entity = new FakeEntity();
        entity = fakeRepository.save(entity);

        entityManager.flush();
        entityManager.clear();

        fakeRepository.findById(entity.getId());
        fakeRepository.findById(entity.getId());

        entityManager.flush();
        entityManager.clear();

        fakeRepository.findOne(entity.getId());
        fakeRepository.findOne(entity.getId());
    }

The projection query is executed twice.
The standard query is executed once.
That seems to prove that hibernate level one cache doesn't cache tuples but only entities

[spring-projects-issues]

Réda Housni Alaoui commented

Mixing the aspects of persisting object and optimizing on what's read is a bad idea in the first place as it means you compromise the two. I'd argue you want to design your entities to form proper aggregates to express clear consistency boundaries and then those either just fit the read model and you can live with the slight performance decrease as the benefit of being able to just use the type as is outweighs that cost. If your read model diverges from the entity I'd rather tweak my queries to return tailored types in the first place rather than messing with the entities themselves.

We have been building (and running on cumulated 1 Petabyte databases) our CRUD application for more than two years with Spring Data JPA and a custom repository to which we can pass EntityGraph as an argument. We don't use any DTO. We pass main entity types in two directions.
I consider that this has saved us time and made the code more maintenable than multiplying the view objects.
Thanks to EntityGraph, we never felt the need to use view objects

[spring-projects-issues]

Réda Housni Alaoui commented

It seems that beside the current topic, you are against JPA EntityGraph.
I think that Spring Data JPA should fully support JPA EntityGraph, including the ability to build or reference them dynamically.

I agree with the fact that the solution must be the less implementation specific possible.
But the EntityGraph is not a concept exclusive to JPA, it exists on MongoDb for example and other database client systems that I am not aware of

[spring-projects-issues]

Oliver Drotbohm commented

What you have tested is not the difference between an entity or an projection but the access via EntityManager.find(…) VS issuing a query. The former hits the first level cace, the latter by definition never. You need to setup proper query caches to see proper caching.

Regarding your custom implementation: that's a perfectly fine approach. It just doesn't mean we should elevate that to something the framework promotes. We neither want to optimize for CRUD scenarios nor for JPA in particular. We need to consider what that feature would mean across all modules.

I am not "against" EntityGraphs, I am against exposing a store specific way of implementing how to define what should be read. When I say EntityGraph I mean the JPA notion of EntityGraph (as already stated twice). And again, there is a solution to that problem available that admittedly might have slightly different trade offs. But then again, nothing prevents you from implementing whatever you want though custom repository extensions. :)

[spring-projects-issues]

Réda Housni Alaoui commented

You are right about the test.
You can't perform an EntityManager.find with Projection, you can with EntityGraph.
So same rules apply about hitting the cache.
The conclusion remains true, projection query result can't be cached by first level cache while EntityGraph ones can.

Query cache is managed by hibernate second level cache.
My test is about first level cache, the one mainly used at my company

[spring-projects-issues]

Réda Housni Alaoui commented

I am not "against" EntityGraphs, I am against exposing a store specific way of implementing how to define what should be read. When I say EntityGraph I mean the JPA notion of EntityGraph (as already stated twice). And again, there is a solution to that problem available that admittedly might have slightly different trade offs. But then again, nothing prevents you from implementing whatever you want though custom repository extensions.

In the current solution, we only have more or less static solution:

• EntityGraph is supported at annotation level
• Projections must exist at compilation time and always bypass level one cache

JPA provides the ability to build them dynamically with level one cache support.
To me, point 1 is incomplete.

Can we find a way to complete it in the official code base without exposing jpa specific way?
Are you planning to deprecate and delete EntityGraph annotation support?

[spring-projects-issues]

Oliver Drotbohm commented

We're running in circles here. There's nothing "incomplete". We support selecting entity graphs per query method. You can use everything of JPA you want in custom implementation code. The point of Spring Data JPA is not to replicate every odd feature JPA has on level above. If we did that, we wouldn't raise the abstraction abstraction level. E.g. there are tons of things you can do with the Criteria API that are not supported in our query methods abstraction. That doesn't mean query methods are incomplete.

There's no way to be found as there already multiple ones present: projections that can vary from call to call and a custom implementation as escape hatch to give you all flexibility. And no, there are no plans to remove the entity graph support we already have in place. Not sure why that question would actually be raised. I think I'm gonna leave it at that as I feel I am repeating myself over and over again and there's no point in doing that any further