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

Move to better naming scheme of methods in repository interfaces

    Details

    • 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

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                olivergierke Oliver Drotbohm
                Reporter:
                olivergierke Oliver Drotbohm
                Last updater:
                Oliver Drotbohm
              • Votes:
                1 Vote for this issue
                Watchers:
                18 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: