| Backport of  HHH-12713 Open is needed. Copy of its description for convenience: JPA EntityGraphs are absolutely essential for good ORM performance in complex products. Different use cases will require different data to be loaded but in-mapping eager/lazy specification is only a global setting, not specific. Eagerly loading data that a specific use case does not need will slow it down, just like lazily loading data that a specific use case does require. Ideally, all the data a use case is known to need should be eagerly loaded and pretty much everything else should be lazy. JPA EntityGraphs (with related hints) are meant to address this and allow separate use cases to specify separate eager/lazy loading/fetching of data. Unfortunately, the JPA EntityGraph system stops short of making the system easy to use. It relies on either very cumbersome annotations to create named graphs or also very cumbersome API to create unnamed ones. Using either results in a hard to read/understand code. It is "uninviting", possibly making developers stay away from it even when they should not. Furthermore, complex products may need runtime discovery of what data is needed by gathering individual and independent specifications from multiple separate modules, then merging them into a union. The only way to do this today is by creating graphs using the API approach (not annotations) via own code or another library I am not familiar with. Finally, applying entity graphs to queries relies on specifying raw hints without even official hint name constants. How these hints are to be applied (or not) in some specific cases is also ambiguous. This gives off an impression that the feature isn't formal and/or taken seriously. We need:
- a much simpler and more approach to creating entity loading/fetching graphs
- enhanced support for manipulating entity lading/fetching graphs, especially to merge them (create unions)
- a better and formal way to apply entity graphs to queries, ideally with less ambiguities
|
