Драгоценный камень Neo4j - эффективные способы уничтожения связанных узлов и отношений

Я знаю, что у драгоценного камня нет встроенного способа обработки уничтожения зависимостей, такого как активная запись dependant: destroy

Есть ли лучшие способы справиться с разрушением цепи?

Например, прямо сейчас я пытаюсь справиться с уничтожением с помощью моих вопросов и ответов.

Каждый вопрос имеет много ответов и каждый ответ имеет один вопрос

Уничтожить вопрос можно так

event_question = EventQuestion.find(params[:id])

event_question.destroy

но если мне нужно разобраться с ответами, а я делаю это через эту ассоциацию, то мне приходится перебирать и уничтожать каждый. Дополнительным недостатком является необходимость проверки существования зависимых узлов/отношений.

Не лучше ли написать более длинный запрос, чтобы иметь дело с поиском вопросов и ответов и уничтожением их одним махом? (или... можете ли вы?) Я знаю, что вы не можете уничтожить запрос-прокси таким образом (например, event_question.answers.destroy)

ОБНОВЛЕНИЕ

Я пытался реализовать эти два запроса с помощью удаления, но удаление не выполняется. Нет сообщения об ошибке прямо сейчас. Подглядывая за методом, совпадения выглядят правильно.

event.users(:u,:rel).query.match("()-[r3]-u").delete(:r3).exec
event.event_questions(:q).event_answers(:a).query.match("event-[r0]-(), q-[r1]-(), a-[r2]-()").delete(:q, :a, :event).exec

ОБНОВЛЕНИЕ 2

Это зашифрованный запрос для первого event.users.

MATCH (event13:`Event`), (u:`User`), event13-[rel:`invited`]-(u:`User`), ()-[r3]-u WHERE ID(event13) = {ID_event13} DELETE r3"

Это выглядит правильно? Но удаление, похоже, не выполняется. Присоединение as или query_as не позволяет выполнить запрос на втором. Это дает мне неопределенный метод as

ПОСЛЕДНЕЕ ОБНОВЛЕНИЕ

Последнее обновление перед переходом к другому вопросу.

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

event.users(:u,:r3).query.match("()-[r]-u").delete(:r3).exec

но этот следующий запрос не удалит вопрос и ответы.

event.event_questions(:q).event_answers(:a).query.match("q-[r1]-(), a-[r2]-()").delete(:q, :a).exec

Я не совсем уверен, зачем нужен матч, но без него он тоже не выполняется. Когда я писал свои функции уничтожения в своем контроллере вопросов/ответов, мне фактически не нужно было удалять отношения. Но, возможно, я сделал что-то фанковое.

Я действительно сделал это

answers = event_question.event_answers

а затем зациклил его и уничтожил каждый ответ, что, казалось, разрушило и ответ, и связь с вопросом. Вопросы и ответы устанавливаются через ассоциации, а не через ActiveRel ... не уверен, что это имеет значение.


ruby-on-rails neo4j destroy neo4j.rb
person Clam    schedule 22.12.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Gem реализует обратные вызовы с ActiveModel. Итак, вы можете сделать:

class EventQuestion
  before_destroy :destroy_answers

  def destroy_answers
    answers.each(&:destroy)
  end
end

Очевидно, что это не самый эффективный способ, так как он уничтожает каждый ответ, который является собственным запросом. Тем не менее, у него есть то преимущество, что все обратные вызовы до/после уничтожения ответов будут вызываться.

Если вы хотите просто удалить их с помощью шифра, вы сможете сделать answers(:a, :r).delete(:a, :r).exec

person Brian Underwood    schedule 22.12.2014
comment
да, это может быть много запросов, если я имею дело с большим количеством связанных узлов. будут ли проблемы в приведенном выше примере, если ответы пусты? я никогда не видел, чтобы .delete или .exec упоминались в документах? - person Clam; 22.12.2014
comment
Вы имеете в виду, если ассоциация ответов пуста? Этого не должно быть, поскольку он просто перебирает пустое перечисление. - person Brian Underwood; 23.12.2014
comment
Кроме того, delete и exec являются частью Query API, который является частью neo4j-core, возможно, поэтому вы его пропустили. Сейчас мы работаем над новым веб-сайтом, и нам нужно лучше организовать нашу документацию, но пока она здесь: github.com/neo4jrb/neo4j-core/wiki/Queries - person Brian Underwood; 23.12.2014
comment
Ах да, всегда забывай о ядре. Я собираюсь попробовать это event.event_questions(:q).event_answers(:a).delete(:q, :a).exec, которое, я думаю, сработает, основываясь на ответе выше. - person Clam; 23.12.2014
comment
я не смог сделать все это в одном запросе, так как у меня также есть такие вещи, как пользователи, которые привязаны к событию, но не являются частью этой цепочки - person Clam; 23.12.2014
comment
Этот event.users(:u,:rel).delete(:rel).exec дает мне ошибку nomethod для удаления в прокси-сервере запроса. Страницы документа сейчас не найдены (я предполагаю, что вы переносите) - person Clam; 23.12.2014
comment
Ах, да, вы также можете удалить в QueryProxy. Если вы хотите удалить узел и все его отношения, даже если они не в цепочке, это может сработать: event.event_questions(:q).event_answers(:a).query.match("q-[r1]-(), a-[r2]-()").delete(:q, :a, :r1, :r2).exec - person Brian Underwood; 23.12.2014
comment
Я добавил свои последние запросы в отредактированную версию вопроса. Нет ошибок или выброшено, но удаление, похоже, не выполняется - person Clam; 24.12.2014
comment
В вашем ruby-коде event является ruby-переменной, но она не объявляется в шифре как переменная, поэтому вы не сможете использовать MATCH и DELETE для нее. Я думаю, вы можете начать эту строку с event.as(:event).event_questions(:q)...., чтобы сделать это. Также посмотрите, что вы получите, если вызовете to_cypher вместо exec, и выведите результат. Он должен показать вам шифрованный запрос, который будет сгенерирован - person Brian Underwood; 24.12.2014
comment
Первый запрос проходит с тем, что кажется правильным запросом, просто не выполняет удаление. Подробнее см. во втором обновлении. - person Clam; 24.12.2014

arrow_upward
0
arrow_downward

Крис и компания работают над рекламой способности dependent destroy. Кажется, в настоящее время он работает над основной веткой драгоценного камня. Кажется, он делает свою работу - хорошо!

https://github.com/neo4jrb/neo4j/pull/653

person Clam    schedule 03.01.2015