Bug #38

Provide facility to bind NamedQueries with named parameters to finder methods

Added by Oliver Gierke almost 2 years ago. Updated 11 months ago.

Status:Closed Start:
Priority:Normal Due date:
Assigned to:Oliver Gierke % Done:

100%
Category:Core DAO Spent time: -
Target version:1.0

Description

Currently we rely on NamedQueries that use anonymous parameters (?). Thus method parameters are applied in order. It would be nice if we could use parameter names to map values to named query parameters:

1 public List<User> findByFirstnameAndCity(String username, String city);
2 
3 @NamedQuery(name = "User.findByFirstnameAndCity", 
4   query = "from User u where u.city = :city and u.firstname = :firstname")

Spring offers a LocalVariableTableParameterNameDiscoverer to facilitate this but requires the code to be compiled with debug mode enabled. Thus we first have to find out whether a query contains named parameters and then try to resolve them from the method name.

This could also be useful on dynamic query creation to prevent spuriously intermingled parameters, which would make query creation more robust against refactorings.

Associated revisions

Revision 7388
Added by Oliver Gierke 11 months ago

  • fixes #38 - allow usage of named parameters in queries and query methods
  • introduced @Param annotation to mark method parameters as to be used with named parameters in queries
  • extended Parameters to hand out detailed information about parameter naming as well as checking for correct usage of the annotation
  • extended QueryCreator to regard named parameters and build the query appropriately
  • let QueryMethod hand out a Parameters instance to retrieve information about the method parameters
  • adapted clients appropriately (esp. NamedHadesQuery )
  • extended tests accordingly

Revision 7389
Added by Oliver Gierke 11 months ago

  • references #38
  • added method to sample project's SimpleUserDao to demonstrate usage of @Param annotation

Revision 7390
Added by Oliver Gierke 11 months ago

  • references #38 - updated reference documentation

History

Updated by Oliver Gierke almost 2 years ago

Actually this is not as straight as I thought it would be. Currently the JPA specification does not allow detection if a (Named)Query contains named parameters. Thus we would have to rely on provider specific implentation to do this.

This concludes in having two variables (debug compile flag, and a user configured provider implemtation base class) that would cause more confusion than the effort is worth.

Therefore I'm going to keep the ticket open but remove it from the 0.3 release.

Updated by Oliver Gierke almost 2 years ago

The JPA Spec 2.0 seems to provide the ability lookup the parameter names from queries. So I guess we delay that feature until we have an RC of that spec available.

Updated by Oliver Gierke over 1 year ago

  • Priority changed from High to Normal

Updated by Oliver Gierke 11 months ago

  • Status changed from New to In progress
  • Target version set to 1.0

Updated by Oliver Gierke 11 months ago

  • Status changed from In progress to Fixed
  • % Done changed from 0 to 100

Status geändert durch Changeset r7388.

Updated by Oliver Gierke 11 months ago

To workaround the restrictions of the persistence provider's APIs as described above I introduced a @Param annotation that now demarcates method parameters that shall be used by name. The provided implementation checks for valid configuration of the method parameters, namely that they are either all (except Pagable and Sort) or non annotated with @Param.

Queries created from the method name can make use of @Param, too, although I think benfit is not overwhelming in this case.

Updated by Oliver Gierke 11 months ago

  • Status changed from Fixed to Closed

Also available in: Atom PDF