Support for more automatic values besides @GeneratedId (JPA_SPEC-36)

[JPA_SPEC-50] @QuerySingleResult Created: 23/Feb/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: mkarg Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

New annotation "@QuerySingleResult(ejbql = "JPAQL QUERY" | namedQuery = "name of query")" should inject the .getSingleResult() output of either a given JPAQL query or of a named query into a field annotated with this annotation.

This is often needed in business applications, for example if the written data is dependend of a aggregate other entities. This is what a trigger would do in databases.



 Comments   
Comment by ldemichiel [ 05/Apr/13 ]

It seems more flexible to me to do this with a producer method.

Comment by mkarg [ 05/Apr/13 ]

While I agree that this solution is not the most flexible one, it possibly opens the most pragmatic solution, as it implies least code to write for the application developer (just one single line naming the query to invoke), offloads as much as possible to lower levers (as the query does all the work on the database server and just transports a single result value over the possibly slow line), and is rather intuitive as it mimics mosty the idea of an INSERT or UPDATE trigger which sets a single value by invoking an aggregating SELECT (like defaulting to the Count of existing rows etc.).

A producer method might be more flexible, but it is not so pragmatic in the daily use, as it implies much more code to write in turn for a flexibility that might not be needed (several lines of code), does not offload by default (depends on the cleverness of the developer, hence, does neither guide nor support him), and is not very intuitive (demands knowledge of a rather complex API instead of simple tagging a field and looking at the IDE's code completion proposals).

So my proposal would be to have both ways and let the developer decide. For daily use the annotation is best. For complex and seldom cases Producer methods are best. I do not see that it is a general, mutual-exclusive API decision, but a use-case driven API usage decision.

Generated at Sat Feb 28 21:26:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.