Вопрос сохранения данных.

[alexis031182]

Вы быстрее задаёте вопросы, нежели чем я успеваю печатать ответы

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

Никак нереализован, у меня другой медиатор, для других целей. Я лишь предложил своё виденье.

Класс состояния виджета - произвольный класс, содержащий в себе данные об изменённых параметрах виджета в определённый момент времени (на момент изменения).

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

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

А я не могу понять, при чём здесь итератор и какой-то обход Я постараюсь сформулировать более понятно идею и напишу чуть позже.

[nata267]

Вы быстрее задаёте вопросы, нежели чем я успеваю печатать ответы

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

Никак нереализован, у меня другой медиатор, для других целей. Я лишь предложил своё виденье.

Класс состояния виджета - произвольный класс, содержащий в себе данные об изменённых параметрах виджета в определённый момент времени (на момент изменения).

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

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

А я не могу понять, при чём здесь итератор и какой-то обход Я постараюсь сформулировать более понятно идею и напишу чуть позже.

обход структуры виджетов или структуры ваших состояний виджетов, обход во время сохранения, чтобы вызвать запросы на обновление данных

[alexis031182]

обход структуры виджетов или структуры ваших состояний виджетов, обход во время сохранения, чтобы вызвать запросы на обновление данных

Ну так это же один раз по кнопке Сохранить, а не при каждом изменении каждого виджета.

[nata267]

в вопросе сохранения данных есть ещё такой момент как иерархические структуры связанные по parent_id. Если поле id autoincrement в базе данных. То при вставке дочерных надо знать id только что вставленного родителя. Допустим с обновлением и удалением более или менее все понятно. Но как решается данная проблема вставки иерархических структур?

[alexis031182]

...
То при вставке дочерных надо знать id только что вставленного родителя.
...

А в чём проблема? Любая БД поддерживает LastInsertId

[nata267]

...
То при вставке дочерных надо знать id только что вставленного родителя.
...

А в чём проблема? Любая БД поддерживает LastInsertId

допустим если обходить эту структуру сверху вниз то эта проблема решаема, а если есть объекты со связями многие ко многим. как с ними быть? Для этих связей создавать отдельные объекты? И сохранять их в последнюю очередь, те когда будут известны id вставляемых связываемых объектов?

[alexis031182]

допустим если обходить эту структуру сверху вниз то эта проблема решаема, а если есть объекты со связями многие ко многим. как с ними быть? Для этих связей создавать отдельные объекты? И сохранять их в последнюю очередь, те когда будут известны id вставляемых связываемых объектов?

Обычно в таких ситуациях связи всегда выделяют в отдельную таблицу. Тогда:
1. вставляются записи данных, получая через lastinsertid их индексы;
2. вставляются записи связей, которые и будут содержать id записей данных.

[nata267]

допустим если обходить эту структуру сверху вниз то эта проблема решаема, а если есть объекты со связями многие ко многим. как с ними быть? Для этих связей создавать отдельные объекты? И сохранять их в последнюю очередь, те когда будут известны id вставляемых связываемых объектов?

Обычно в таких ситуациях связи всегда выделяют в отдельную таблицу. Тогда:
1. вставляются записи данных, получая через lastinsertid их индексы;
2. вставляются записи связей, которые и будут содержать id записей данных.

а если в одном из связываемых объектов создать список указателей на другие связываемые объекты. Сохранить сначала их, а потом сохранить первый связываемый объект. Пройтись по списку указателей на связываемые объекты, у которых уже известны id и создать связи. Или даже хранить не указатели на объекты, а указатели на связи с объектами. и у связей тоже будут статусы deleted, modified

[nata267]

допустим если обходить эту структуру сверху вниз то эта проблема решаема, а если есть объекты со связями многие ко многим. как с ними быть? Для этих связей создавать отдельные объекты? И сохранять их в последнюю очередь, те когда будут известны id вставляемых связываемых объектов?

Обычно в таких ситуациях связи всегда выделяют в отдельную таблицу. Тогда:
1. вставляются записи данных, получая через lastinsertid их индексы;
2. вставляются записи связей, которые и будут содержать id записей данных.

а если в одном из связываемых объектов создать список указателей на другие связываемые объекты. Сохранить сначала их, а потом сохранить первый связываемый объект. Пройтись по списку указателей на связываемые объекты, у которых уже известны id и создать связи. Или даже хранить не указатели на объекты, а указатели на связи с объектами. и у связей тоже будут статусы deleted, modified

вопрос не в очередности, а в том как делать обход?? в какой структуре это хранить и как делать обход этой структуры в момент сохранения. в любом случае придется делать приоритет. то есть объекты одного типа сохраняются раньше объектов другого типа

[alexis031182]

Я думал Вы про БД спрашивали выше. Всё смешалось в доме Облонских.

[alexis031182]

вопрос не в очередности, а в том как делать обход??

Обход по идее с верхнего родительского уровня начинать надо.

в какой структуре это хранить и как делать обход этой структуры в момент сохранения.

Под "структурой" что Вы понимаете? У Вас есть дерево объектов. Родители со ссылками (указателями) на дочерние объекты. Зачем нужны какие-то дополнительные мегаобразования?

в любом случае придется делать приоритет. то есть объекты одного типа сохраняются раньше объектов другого типа

Здесь Вы уже на своей волне.

[nata267]

C одной табличкой бд все здорово получается и сохранение всех изменений и действия undo/redo, cut, copy, paste. но как только появляется связь с другой табличкой "многие ко многим" с undo/redo и сохранением всех действий  получается какая-то жесть... без undo/redo и с сохранением сразу в базу все получается. очень хочется плюнуть на это дело.

[alexis031182]

Бейтесь, не смотря ни на что. Попробуйте мыслить нестандартно. Или в конце концов просто отложите поиск решения на лучшее время, а пока займитесь другой тактической задачей. Иногда идеи приходят невзначай, провидение подскажет.

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

Undo/redo, как очень справедливо отметил Игорь, весьма нетривиальная задача. Вполне вероятно, что со сложносоставными объектами она вообще не имеет решения. Точнее сказать, затраты на обслуживание объектов в "корзине" становятся столь высокими, что проще действительно "забить" на это дело. Суперуниверсализм не всегда достижим. Впрочем, сдаваться и опускать руки - последнее дело.

[Igors]

C одной табличкой бд все здорово получается и сохранение всех изменений и действия undo/redo, cut, copy, paste. но как только появляется связь с другой табличкой "многие ко многим" с undo/redo и сохранением всех действий  получается какая-то жесть... без undo/redo и с сохранением сразу в базу все получается. очень хочется плюнуть на это дело.

Да, при "связках объектов" (даже без базы) undo часто получается исключительно трудным и требует затрат/кода во много раз превышающего само действие.

Бейтесь, не смотря ни на что. Попробуйте мыслить нестандартно. ....Суперуниверсализм не всегда достижим. Впрочем, сдаваться и опускать руки - последнее дело.

Слова-то хорошие, но подозреваю что без конкретного примера/задачи эффект (увы) все же нулевой 
Проблема в том что привести такой пример очень трудно. Или "все просто и все получается, какой чудесный паттерн" или др крайность - такая тонна специфики что понять человеку вне проекта нереально

[nata267]

C одной табличкой бд все здорово получается и сохранение всех изменений и действия undo/redo, cut, copy, paste. но как только появляется связь с другой табличкой "многие ко многим" с undo/redo и сохранением всех действий  получается какая-то жесть... без undo/redo и с сохранением сразу в базу все получается. очень хочется плюнуть на это дело.

Да, при "связках объектов" (даже без базы) undo часто получается исключительно трудным и требует затрат/кода во много раз превышающего само действие.

Бейтесь, не смотря ни на что. Попробуйте мыслить нестандартно. ....Суперуниверсализм не всегда достижим. Впрочем, сдаваться и опускать руки - последнее дело.

Слова-то хорошие, но подозреваю что без конкретного примера/задачи эффект (увы) все же нулевой 
Проблема в том что привести такой пример очень трудно. Или "все просто и все получается, какой чудесный паттерн" или др крайность - такая тонна специфики что понять человеку вне проекта нереально

У меня задача вроде бы и простая, но чето никак. суть в том что у меня есть окошко с QTreeView+QStandardItemModel. Дерево состоит из двух уровней. Первый уровень - это данные из одной таблицы. Второй уровень - данные из другой таблицы. Между этими табличками связь "многие-ко-многим". То есть если я добавляю дочерний узел, то эта запись должна пойти в базу и прицепиться к родительскому узлу. Для наглядности картинку с окошком прицепила. Вот если я убираю дочерние узлы, то реализуется все на раз-два. А сними начинается куча проблем. Дочерние узля кстати можно создавать и в окошке и выбирать ранее созданные из базы этих объектов (по тз было перетаскиванием, короче там ещё dragand drop замешан))), вот.