Support for more automatic values besides @GeneratedId
[JPA_SPEC-50] @QuerySingleResult Created: 23/Feb/13 Updated: 05/Apr/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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.
|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.