Allow programmatic use of entity graphs [DATAJPA-560]

[spring-projects-issues]

Andreas Schilling opened DATAJPA-560 and commented

For clearly separated (query) use cases having different repository methods with different entity graphs applied is a fine way to control what data is fetched during a query. Then we can give this kind of query a clear name.

With a larger number of graphs or when it should be possible to dynamically decide before a query what graph should be used (e.g. the user may select the amount of detail data she sees) however a programmatic way to apply a graph would be good to keep down the amount of query methods.
This is especially the case if the "base query" stays the same (i.e. no dynamic WHERE or the like).

All this is already possible with Specifications, using entity graphs however would feel more natural and result in less boilerplate code

---

Affects: 1.6 GA (Dijkstra)

Issue Links:

• DATAJPA-1291 Allow findById caller to choose which lazy relations should be fetched
  ("is depended on by")

• DATAJPA-645 Enable JPA 2.1 EntityGraphs to be specified dynamically
  ("is duplicated by")

• DATAJPA-466 Add support for lazy loading configuration via JPA 2.1 fetch-/loadgraph

• DATAJPA-696 Support ad-hoc fetch graph configurations on repository methods

Referenced from: pull request #112

4 votes, 8 watchers

[spring-projects-issues]

Thomas Darimont commented

Hi Andreas,

this would be a valuable feature :)

Do you have some concrete examples in mind how you would use such a feature?
I can image providing API support for this through a special parameter type (Fetching / FetchRequest) similar to Pageable and Sort.
Such a "FetchRequest" could describe the fetch graph name and type that should be applied.

Cheers,
Thomas

[spring-projects-issues]

Andreas Schilling commented

Hi Thomas,

yes, using the special parameter would be definitely one of the main usage scenarios and also be consistent with what's already there for the other special types.
Apart from that in combination with specifications. That would help with what we have alot in our projects: same query, multiple different (child-)data needs.
But maybe you already meant with "API" basically all places where currently already Pageable and Sort appear (e.g. also JpaSpecificationExecutor, QueryDslPredicateExecutor, ...)?

Regards,

Andreas

[spring-projects-issues]

liujiong commented

please review the PR

[spring-projects-issues]

Daniel Frank commented

Any news about this issue?

[spring-projects-issues]

Oliver Drotbohm commented

I just ran across the PR during a review. The PR is not gonna cut it as it removes public API. Also, it doesn't really use the Spring Data means to declare and obtain special parameters.

Generally speaking, I'm not too sure I'd like to see this implemented at all. What we'd end up with is store specific API to be exposed through repository methods and thus leaking into clients. This is something you'd like to avoid by all means as the sole purpose of a repository is hiding the actual persistence technology used. Plus, to apply this stuff consistently we'd need to introduce JPA-specific extensions of QueryDslPredicateExecutor etc. It all of a sudden scatters through all of the APIs

[spring-projects-issues]

Andreas Schilling commented

Oliver,

I definitely see your points. Thinking a bit more about it right now, it's not only the leaking but already simply the addition of optional parameters you may or may not need depending on the use case which I wouldn't like to see myself in a codebase :-)
I just dropped by because I saw https://jira.spring.io/browse/DATAJPA-696 and I like its AOP approach alot. For my very personal use cases (from which this issue here arose) that's an excellent fit.
So, I would be totally fine with having this issue closed.

[spring-projects-issues]

Jens Schauder commented

I think this discussion is done. We even manage to convince the OP ;o)

[JordanDurieux]

Thank you @schauder for pointing me to this existing issue.

If possible, I would like this feature to be reexamined.
I disagree with @odrotbohm, in this context you cannot hide the persistence technology used to the client.

The current alternative consists in adding X methods in the repository saying : findBySomethingAndFetchThis, findBySomethingAndFetchThisAndThat, which is actually equivalent and more verbose.

Could you have a look at #2556 ?
I can submit a PR with my proposition (which is using JpaEntityGraph as a special parameter).

[odrotbohm]

I disagree with @odrotbohm, in this context you cannot hide the persistence technology used to the client.

Why not? EntityGraphs of course do what you describe: they provide a persistence technology specific way of defining which parts of an aggregate to load. And, yes, if a client wanted to make programmatic use of them, it can't do so without referring to the concept. That's a problem of entity graphs, but it doesn't mean that it's a good idea to break the abstraction with them. They suffer from more problems even, as persisting the partially loaded aggregates will wipe data if you're not careful.

Also, consider that there are way less invasive approaches to the fundamental problem. Using DTO or interface projections, and by that basically introducing a dedicated model for specific read requirements, are a much better way to approach this problem. They're store- and even Spring Data independent, and work consistently across the different data modules. Plus, they clearly separate read models from write ones and do not overload the latter with the former.