#java #mongodb #spring-boot #neo4j
#java #mongodb #весенняя загрузка #neo4j
Вопрос:
У меня есть пользовательская сущность, которую я хочу сохранить в двух базах данных: одна в MongoDB и одна в Neo4j:
@Node("User")
@Document
public class User {
@Id
@GeneratedValue(UUIDStringGenerator.class)
@org.springframework.data.annotation.Id
private String id;
//some other fields
private Set<SomeObject> objects = new HashSet<>();
//getters and setters
}
Это мои зависимости для обеих баз данных:
<dependency>
<groupId>org.neo4j.springframework.data</groupId>
<artifactId>spring-data-neo4j-rx-spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>
Теперь представьте, что я хочу, чтобы набор объектов сохранялся в моем MongoDB, но не в моей базе данных Neo4j. Если я отмечу это как @Transient, оно не будет сохранено ни в одной из них. Есть ли какой-нибудь способ сделать это?
Комментарии:
1. Есть ли spring-data-neo4j в ваших зависимостях?
2. Нет. Есть только spring-data-neo4j-rx.
3. Spring Data Neo4j RX ( github.com/neo4j/sdn-rx — репозиторий архивирован) был заменен весенними данными Neo4j 6 ( github.com/spring-projects/spring-data-neo4j ). Вам следует обновиться.
Ответ №1:
Раньше такая поддержка сценариев такого рода существовала давным-давно (около Spring Data Neo4j 3), но, похоже, ее очень сложно правильно поддерживать, поэтому встроенной поддержки частичных объектов больше нет.
Например, как вы откатываете транзакцию, если часть сущности правильно сохранена (в хранилище данных A), а другая — нет (в хранилище данных B)? Что, если откат завершится неудачей?
Если вы все еще хотите пойти по этому пути, я думаю, вам нужно будет явно использовать Neo4jTransactionManager and MongoTransactionManager (или их реактивные варианты) и полагаться на JTA или аналогичные для координации отдельных транзакций.
Для ваших объектов я бы предположил, что может сработать отказ от аннотаций Spring Data Commons и использование аннотаций, специфичных для хранилища данных.