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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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