Да тут скорее в другом вопрос, я подсознательно выстрою правильную последовательность, а тут задали вопрос и встал в ступор

И это не пыхи приколы а си

У каждого оператора ведь свой приоритет

)

На самом деле прекрасно понимаю как это отработает

опять же
&$a && $b
&$a & &$b
это ведь тоже самое?

Ребят, всем привет. Делал кто-нибудь слепок состояния модели? Задача состоит в том, что надо сохранять в истории состояние модели при редактировании каждый раз и иметь возможность редактировать это состояние(через ту же форму, через которую редактируется сама модель). У меня уже есть решение, но хотелось бы послушать как решили бы эту задачу другие разработчики. То есть основная задача в том, что есть некий архив изменений модели, который можно отредактировать

Причём редактирование из архива должно быть идентичным, как и при обычном редактировании сущности

Соответственно там полный фарш из связей и тп

Напоминает аудит/es, но чтобы редактировать — это что-то новое. Прошлое нельзя изменить. Ты собираешься редактировать и изменения применить к текущей модели?

Нет, есть некоторая бизнес потребность, когда сущность редактируется в рамках некое собрания(для простоты назовём так).  И нужно знать состояние модели при каждом таком изменении сущности. То есть на выходе у меня главная сущность редактируется и параллельно должна быть некая история изменений, которую можно редактировать, причём на той же форме, что и основная сущность. При редактировании истории редактируется только сама Истрия

История

Сущность остаётся с прежними данными

Хорошо, и в чем сложность? Ты можешь на время редактирования «наложить» на модель изменения того времени, если тебе нужны связи, и использовать одну и ту же форму. Короче, не зная, в чем проблема, хз что советовать.

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

То есть в идеале хотелось бы как-нибудь выкрутиться так, чтобы работа с моделью и с арзивом была идентичной, но источник сохранения подменялся(и соответственно алгоритм сохранения)

На данный момент планирую просто json всех значений держать в отдельной таблице

И это еще я не беру проблему с сохранением связей модели на тот момент. Их тоже нужно архивировать очевидно

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

Тоже про это думаю