Dane źródłowe MongoDB próbuje generować zapytania dla niestandardowych metod repozytorium.

Question

Na podstawie Spring Data Document documentation udostępniłem niestandardową implementację metody repozytorium. Nazwa niestandardowej metody odnosi się do nieruchomości, która nie istnieje w obiekcie domeny:

@Document 
public class User { 
    String username; 
} 

public interface UserRepositoryCustom { 
    public User findByNonExistentProperty(String arg); 
} 

public class UserRepositoryCustomImpl implements UserRepositoryCustom { 
    @Override 
    public User findByNonExistentProperty(String arg) { 
     return /*perform query*/; 
    } 
} 

public interface UserRepository 
     extends CrudRepository<?, ?>, UserRepositoryCustom { 

    public User findByUsername(String username); 
} 

Jednak być może ze względu na nazwę metody wybrałem (findByNonExistentPropertyName), Wiosna danych próbuje zanalizować nazwę metody, i stwórz z niego zapytanie. Gdy nie można znaleźć nonExistentProperty w User, zgłoszony zostanie wyjątek.

Możliwe rozdzielczości:

1. Czy popełniłem błąd w jaki sposób zapewnić realizację metody niestandardowej?
2. Czy można polecić Spring, aby nie próbowała generować zapytania na podstawie nazwy tej metody?
3. Czy muszę po prostu unikać używania jakichkolwiek prefiksów rozpoznawanych przez Spring Data?
4. Żadne z powyższych.

Dziękujemy!

Answer 1

Twoja klasa implementacji musi być nazwana UserRepositoryImpl (jeśli trzymasz się domyślnej konfiguracji) podczas próby sprawdzenia jej na podstawie znalezionej nazwy interfejsu repozytorium danych Spring. Powodem, dla którego zaczynamy od tego, jest to, że nie możemy niezawodnie wiedzieć, który z interfejsów, który rozszerzasz, jest tym, który ma niestandardową implementację. Biorąc pod uwagę scenariusz, jak to

public interface UserRepository extends CrudRepository<User, BigInteger>, 
    QueryDslPredicateExecutor<User>, UserRepositoryCustom { … } 

musielibyśmy jakoś ciężko kod interfejsy nie do sprawdzenia dla klas niestandardowych wdrożeniowych, aby zapobiec przypadkowemu pick-upy.

Generalnie sugerujemy wymyślanie konwencji nazw, na przykład przyrostka Custom dla interfejsu zawierającego metody, które mają zostać zaimplementowane ręcznie. Następnie można skonfigurować infrastrukturę repozytorium odebrać klasy implementacji używając CustomImpl jako przyrostek za pomocą atrybutu elementu repositoriesrepository-impl-postfix:

<mongo:repositories base-package="com.acme" 
        repository-impl-postfix="CustomImpl" /> 

Nie ma więcej informacji na ten temat w reference documentation ale wydaje się, że co najmniej krótko sprawdziłem to. :)