jakartaee / persistence

https://jakartaee.github.io/persistence/
Other
196 stars 58 forks source link

Allow simplified form for @NamedEntityGraph #118

Open lukasj opened 8 years ago

lukasj commented 8 years ago

Spin off from #98:

as of 2.1 definition of @NamedEntityGraph can be too verbose, see ie https://github.com/javaee-samples/javaee7-samples/blob/master/jpa/entitygraph/src/main/java/org/javaee7/jpa/entitygraph/Movie.java

It would be good to allow simplified form, ie:

@NamedEntityGraph(
    attributes = {"id", "name", "description", "subgraph.property", "anotherSubgraph.property"}
)
lukasj commented 6 years ago
lukasj commented 8 years ago

@glassfishrobot Commented Reported by @lukasj

lukasj commented 8 years ago

@glassfishrobot Commented pbenedict said: I am not a fan of @NamedEntityGraph because attribute string names (1) aren't typically discoverable by IDEs for refactoring and (2) are too far removed from the actual fields themselves. What about allowing a second option – reversing the concept – so that attributes specify what graphs they belong to? I am sure there are use cases for both.

Example:

@Column
@NamedEntityGraphMember("movieWithActors")
private String name;
lukasj commented 8 years ago

@glassfishrobot Commented radcortez said: Seems a good idea, but it might harder to read which properties are loaded in each EntityGraph. I'm assuming, that a @NamedEntityGraphMember in a field property could have an array of graphs, so it would make it harder to read when you might have something like this:

@Column
@NamedEntityGraphMember({"graph1", "graph2", "graph3"})
private Long id;
@Column
@NamedEntityGraphMember({"graph2", "graph3"})
private String name;
@Column
@NamedEntityGraphMember({"graph2"})
private String anotherName;

You get the idea. It becomes more complex when you have an entity with more fields.

lukasj commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JPA_SPEC-118

gavinking commented 1 year ago

@NamedEntityGraph as it exists today is IMO not usable at all.

I like the concept of the @NamedEntityGraphMember annotation, which is quite similar to Hibernate's @FetchProfileOverride described here:

https://docs.jboss.org/hibernate/orm/6.3/introduction/html_single/Hibernate_Introduction.html#fetch-profiles

A different option is an embedded minilanguage, something @sebersole has experimented with, which could look like:

title, author(firstName, lastName), publicationDate, publisher(name)

and could easily go into an annotation:

@NamedEntityGraph(graph="title, author(firstName, lastName), publicationDate, publisher(name)")

This is an issue we should explore further when we have time.

AleksNo commented 1 year ago

Hi.

True, @NamedEntityGraph is almost unusable. It is ugly and it becomes very messy very quickly. Especially if you want more than one @NamedEntityGraph on an Entity. I use dynamic EntityGraphs all the time because of it.

Cheers

sebersole commented 1 year ago

The "graph language" actually grew initially out of the desire to make building dynamic graphs more concise fwiw. In Hibernate you can say

EntityGraph<Book> graph = GraphParser.parse( 
        Book.class, 
        "title, author(firstName, lastName), publicationDate, publisher(name)" ,
        entityManager
);

It would be nice to have that option for named graphs as well.