Улучшение ситуации: миграция данных Spring Neo4j 3.x на 4.0 — сессии и репозитории

Ничего сверхсложного здесь нет, но давайте подробнее рассмотрим жизненный цикл сеанса, а также фабрики сеансов, которая также может иметь область действия.

Жизненный цикл сессии

Разработчик может настроить жизненный цикл сеанса: можно предположить, что сеанс с более длинной областью действия потребует дополнительных затрат памяти, но приведет к более эффективному выполнению запросов с учетом локального кэша сущностей. Однако, если эти объекты не будут периодически перезагружаться, можно пропустить изменения, сделанные другими пользователями, и в конечном итоге работать с устаревшими объектами.

Если кто-то решит использовать сеансы с более короткой областью действия, накладные расходы памяти практически исключаются, хотя запросы могут быть не такими эффективными, как в противном случае. Это особенно верно для операций сохранения, так как сеанс может не знать об объектах, которые были первоначально загружены, и поэтому обновит все объекты.

Итак, есть компромиссы.

Рекомендуется настроить область сеанса так, чтобы она соответствовала тому, что можно считать «единицей работы» в вашем приложении. 

Из руководства SDN 4.0 :

«Что это означает, зависит от сценария использования, но в типичном веб-приложении Spring мы рекомендуем использовать сеанс в области запросов или в рамках сеансов HTTP. В любом случае, если вы убедитесь, что загружаете свежие данные в начале каждого единица работы, то целостность данных не должна быть проблемой «.

Не следует упускать из виду фабрику сессий. Фабрика сеанса устанавливает любые метаданные отображения графов объектов. Хотя рекомендуется оставить область действия фабрики сеансов такой же, как в приложении, область действия можно установить более узкой, если это необходимо, хотя выгоды от этого, вероятно, будут незначительными.

Итак, что я могу сделать с сеансом?

Поскольку сессия  управляет Neo4jTemplate , и вы, несомненно, знакомы с Neo4jTemplate  прошлого, вы можете себе представить, что сессия — это то, что обеспечивает большинство взаимодействий с самим графом.

Тем не менее, между старым и новым  классами Neo4jTemplate есть существенные различия .

В предыдущих версиях SDN  класс Neo4jTemplate позволял нам напрямую взаимодействовать с узлами и отношениями графа, позволяя создавать отношения, находить конкретные узлы по некоторому индексу и т. Д.

Эти удобства были убраны, применяя более кайферно-ориентированный подход; то есть операции, которые мы обычно выполняем с узлами и отношениями, теперь в основном осуществляются посредством работы с нашими объектами POJO и их сохранения, или с помощью запросов Cypher, отправляемых через  класс Neo4jTemplate . (Тем не менее, вы все равно можете загрузить несколько узлов на основе свойств / типов объектов.)

Давайте посмотрим на быстрый пример.

В моем оригинальном магазине фон Неймана у нас был следующий метод:

public Purchase makePurchase(Neo4jOperations template, Stock item, int quantity)
{
  return template.createRelationshipBetween(this, item, Purchase.class, "PURCHASED", false);
}

public Purchase makePurchase(Neo4jOperations template, Stock item, int quantity)
{
  final Purchase purchase = new Purchase();
  purchase.setCustomer(this);
  purchase.setItem(item);

  template.save(purchase);

  return purchase;
}

public interface GameRepository extends GraphRepository<Game> {
Game findByGameId(String id);

@Query("MATCH (g1:Game {gameId: {0} }), (g2:Game {gameId: {1} }), p = shortestPath( (g1)-[*]-(g2) ) RETURN p")
Iterable<Map<String, Object> > getPath(String game1Id, String game2Id);
}