Разрешение типов поддокументов с помощью Spring Data и MongoDB

Я сталкиваюсь с ошибкой в ​​репозитории Spring Data, когда он пытается разрешить выражение свойства:

public interface ContractRepository
    extends MongoRepository<Contract,String> {
    public List<Contract> findByCodeBindings(String binding);
}

Вот соответствующие части Contract:

@Document(collection="CONTRACTS")
public class PersistentContract extends BaseContract {
    @PersistenceConstructor
    public PersistentContract(String name, Version version, Code code) {
        super(name, version, code);
    }
}

Code - это интерфейс, реализованный CodeImpl. Он содержит свойство bindings, у которого есть геттер и сеттер в Code. Таким образом, выражение свойства запроса предназначено для поиска этих контрактов с вложенным документом кода, содержащим заданную привязку. Все идет нормально.

Однако проблема в том, что IllegalArgumentException выбрасывается:

java.lang.IllegalArgumentException: No property bindings found on my.company.Code!
 org.springframework.data.mapping.context.AbstractMappingContext.getPersistentPropertyPath(AbstractMappingContext.java:225)

Отладка этого раздела кода показывает, что Spring Data выделяет выражение и определяет наличие свойства типа Code. Однако, поскольку Code - это интерфейс, для него нет перечисленных свойств.

Есть ли способ намекнуть Spring Data, что либо Code имеет это свойство, либо CodeImpl является фактическим типом свойства code? Я удивлен, что библиотека не пытается анализировать геттеры или сеттеры интерфейса.

Это использует spring-data-commons 1.5.1.RELEASE и spring-data-mongodb 1.2.1.RELEASE.

Цените помощь.


java mongodb spring-data spring-data-mongodb
person Tim Clemons    schedule 26.04.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Мое решение состояло в том, чтобы вообще избегать интерфейсов в постоянном объекте. Итак, BaseContract стал следующим:

public abstract class BaseContract<T extends Code> {
    public abstract T getCode();
}

И PersistentContract был реализован в виде конкретных классов:

public class PersistentContract extends BaseContract<CodeImpl> {
}

Похоже, что это обеспечивает правильный баланс между кодированием интерфейсов в базовом классе и удовлетворением потребности Spring Data в конкретных классах.

person Tim Clemons    schedule 01.05.2013