Spring Data MongoDB tenta di generare query per i metodi di repository personalizzati

Question

In base allo Spring Data Document documentation, ho fornito un'implementazione personalizzata di un metodo di repository. Il nome del metodo personalizzato fa riferimento a una proprietà che non esiste nell'oggetto dominio:

@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); 
} 

Tuttavia, forse a causa del nome del metodo che ho scelto (findByNonExistentPropertyName), Primavera dei dati tenta di analizzare il nome del metodo, e creare una query da esso. Quando non riesce a trovare nonExistentProperty in User, viene generata un'eccezione.

Possibili risoluzioni:

1. ho fatto un errore nel modo in cui fornisco l'implementazione del metodo personalizzato?
2. C'è un modo per indicare a Spring di non tentare di generare una query in base al nome di questo metodo?
3. Devo solo evitare di utilizzare uno dei prefissi riconosciuti da Spring Data?
4. Nessuno dei precedenti.

Grazie!

Answer 1

La classe di implementazione deve essere denominata UserRepositoryImpl (se ci si attiene alla configurazione predefinita) mentre si cerca di cercarlo in base al nome dell'interfaccia del repository Spring Data trovato. Il motivo per cui iniziamo con quello è che non possiamo sapere in modo affidabile quale delle interfacce estendiate sia quella con l'implementazione personalizzata. Dato uno scenario come questo

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

avremmo dovuto in qualche modo codificare le interfacce di non verificare la presenza di classi di implementazione su misura per prevenire accidentali pick-up.

Quindi quello che generalmente suggeriamo è di creare una convenzione di denominazione, diciamo il suffisso Custom per l'interfaccia contenente i metodi da implementare manualmente. È quindi possibile impostare l'infrastruttura repository per raccogliere le classi di implementazione utilizzando CustomImpl come suffisso utilizzando l'attributo repository-impl-postfix dell'elemento repositories:

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

C'è di più informazioni su questo nel reference documentation ma sembra di avere almeno brevemente controllato. :)