Uploaded image for project: 'Spring Data Commons'
  1. Spring Data Commons
  2. DATACMNS-944

Move to better naming scheme of methods in repository interfaces



    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0 M3 (Kay)
    • Component/s: Repositories
    • Labels:
    • Sprint:
      Ingalls RC1, Ingalls GA, Kay M2, Kay M3


      The current naming scheme for methods in CrudRepository cause quite a few problems. Especially the methods taking parameters that are generic type variables. Under bad circumstances they could effectively resolve to the same methods and cause ambiguities.

      With the 2.0 release we have the chance to correct those mistakes and the following scheme is suggested (pseudo code):

      // Previously ID extends Serializable
      interface CrudRepository<T, ID> {
      	<S extends T> … save(S entity);
      	// Previously save(Iterable)
      	<S extends T> … saveAll(Iterable<S> entities);
      	// Previously findOne(ID)
      	… findById(ID id);
      	// Previously exists(…)
      	… existsById(ID id);
      	… findAll();
      	… findAllByIds(Iterable<ID> ids);
      	… count();
      	// Previously delete(ID)
      	… deleteById(ID id);
      	… delete(T entity);
      	// Previously delete(Iterable)
      	… deleteAll(Iterable<? extends T> entities);
      	… deleteAll();

      The methods that are effected by a change are marked with a comment here. The new scheme is driven by the following requirements:

      1. We're able to uniquely find methods by name and raw parameter type (ideally by the number of parameters in the first place). Previously, the generics of esp. the delete(…) methods could effectively resolve to the same type.
      2. Methods named …All(…) affect a collection of items and/or return one.
      3. Methods taking an identifier are named …ById(…).
      4. With that in place, we can reliably drop the ID extends Serializable requirement, which is not possible without that change as then the delete(…) methods would be ambiguous.


          Issue Links



              olivergierke Oliver Drotbohm
              olivergierke Oliver Drotbohm
              Last updater:
              Spring Issues Spring Issues
              1 Vote for this issue
              18 Start watching this issue