Устранение неоднозначности скомпилированных классов в Spring Data - PullRequest
Новая
       6

Устранение неоднозначности скомпилированных классов в Spring Data

1 голос
/ 29 марта 2019

Я пытаюсь использовать Spring для написания документа в MongoDB, и я получаю org.springframework.data.mapping.MappingException: Ambiguous field mapping detected!

Проблема в том, что эта неоднозначность происходит от скомпилированного класса, который наследуется от другого скомпилированного класса, поэтому я не могу использовать аннотацию @Field для изменения имени поля вручную.

Есть ли способ сообщить Spring, как разрешать неоднозначные отображения полей без изменения кода классов?

Класс, который я пытаюсь сохранить, выглядит следующим образом: 

data class BehaviouralEvent(
    val sources: Set<BehaviouralEvent>,
    override val activity: Activity,
    override val start: Instant = Instant.now(),
    override val end: Instant = Instant.now(),
    override val lifecycle: Lifecycle = Lifecycle.UNKNOWN
) : Event(activity, start, end, lifecycle) {

    constructor(
        sources: Set<BehaviouralEvent>,
        activityID: String,
        start: Instant = Instant.now(),
        end: Instant = Instant.now(),
        lifecycle: Lifecycle = Lifecycle.UNKNOWN
    ) : this(sources, Activity.from(activityID), start, end, lifecycle)

    constructor(
        sources: Set<BehaviouralEvent>,
        event: Event
    ) : this(sources, event.activity, event.start, event.end, event.lifecycle)
}

Когда я пытаюсь сохранить документ с этой структурой (с MongoRepository<BehaviouralEvent, String>), я получаю неоднозначное сопоставление полей для всех переопределенных атрибутов (активность, начало, конец и жизненный цикл).

Цените любые идеи или обходные пути.

1 Ответ

0 голосов
/ 04 апреля 2019

tl; dr На момент написания этой статьи не было никакого решения.

Слой отображения в настоящее время не имеет средств, чтобы сказать, какое из свойств должно быть сохранено, если одно «затеняет» другое. Поэтому у нас есть эта проверка в метаданных сущности.

Теперь, если вы попытались немного ослабить уникальную проверку поля в BasicMongoPersistentEntity для типов Kotlin, добавив что-то вроде 

if(isKotlinType(property.getOwner()) && !propety.hasGetter()) {
    return;
}

хранилище больше не будет жаловаться во время создания. Тем не менее, слой отображения все еще должен определить, какие из представленных свойств будут сохраняться, так как они зависят от порядка проверки, они по-прежнему переопределяют друг друга, и, вероятно, в конечном итоге сохраняется неправильное состояние. Особенно при переопределении val с var.

Я открыл DATAMONGO-2250 , чтобы продолжить расследование и посмотреть, можем ли мы что-то с этим сделать.

...