AD
насколько я помню, проблемы будут только с удалением через двойную вложенность, так что удаление через references в миграциях либо ручками
Size: a a a
2020 July 09
DS
Это когда юзеры отвечают, да. А надо создавать все эти вопросы для начала
не представляю сценарий, где я пишу вопросы и сам на них отвечаю. Только если это не FAQ какой-нибудь. Почему вариант создать сущность с вопросами, а по идентификатору сущности сохранять список ответов не подходит?
AD
не представляю сценарий, где я пишу вопросы и сам на них отвечаю. Только если это не FAQ какой-нибудь. Почему вариант создать сущность с вопросами, а по идентификатору сущности сохранять список ответов не подходит?
так нет, вопросы отдельно создаются и сущность есть, просто для создания тоже api нужно
AD
опрос -> вопрос -> вариант ответа, если я правильно поняла
МБ
опрос -> вопрос -> вариант ответа, если я правильно поняла
Правильно
DS
а понял, обсуждение видимо про то, как варианты ответов хранить, а не сами ответы
МБ
а понял, обсуждение видимо про то, как варианты ответов хранить, а не сами ответы
Как хранить понятно. Как создавать было не понятно
AN
Ну вообще с вложенностью и двойной вложенностью экто работает топорно, нужно быть осторожнее. Затирает записи при cast_assoc, меняет id записей если они не пришли с клиента, в общем нужно все внимательно проверять и иной раз проще и надежнее руками записи обрабатывать
AN
особено если many_to_many
AD
Ну вообще с вложенностью и двойной вложенностью экто работает топорно, нужно быть осторожнее. Затирает записи при cast_assoc, меняет id записей если они не пришли с клиента, в общем нужно все внимательно проверять и иной раз проще и надежнее руками записи обрабатывать
не очень понятно, если записи не пришли с клиента - если поле вообще не заполнено? и при каком кейсе затирает записи
AN
Ну если идём с верхнего уровня, у нас было 1-5 записей, а с клиента пришло 1-2 записи, то остальные 3 затрутся
AD
так это же логично
AN
Если поле id с клиента не пришло, то старая запись затирается и создаётся новая с новым id6
AD
а откуда бд должна понять что это именно та запись без id 🤷♀️
AN
Так ниоткуда, но я же говорю, алгоритм топорный и его надо хорошо понимать и не всегда получается использовать. Особенно если это many to many
AD
Ну если идём с верхнего уровня, у нас было 1-5 записей, а с клиента пришло 1-2 записи, то остальные 3 затрутся
кстати если не путаю
on_replace: update как раз решает эту проблемуAD
Так ниоткуда, но я же говорю, алгоритм топорный и его надо хорошо понимать и не всегда получается использовать. Особенно если это many to many
ну я вообще не понимаю как это в любом другом orm/datamapping-ге должно работать без id
AD
сопоставлять поля записи?
AD
не хочешь чтобы запись менялась - не отправляй ее и используй on_replace: update
AN
Да не всегда получается решить средствами ассоциаций экто и в случаях чуть сложнее опросника на коленке очень часто только через Repo.transaction можно реализовать бизнес логику