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

ну вообще-то пользователь указывает куда вставлять, например поле выделенного элемента в пердставлении, вот и узнаешь индекс этого элемента через курентИндекс() и после него вставляешь.

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

для примера приведу таблицу в бд и связанную с ней модель на основе QSqlTableModel: допустим, мы подписались на уведомления о событиях бд (либо наплодили хп/триггеров в бд и по периодически зачитываем таблицу изменений) - если третья сторона добавит в таблицу свои записи, мы об этом узнаем
в лучшем случае узнаем значение примарикей для изменившейся записи и тогда два варианта: найдём в модели индекс, содержащий данное значение ключа, и изменим данные всей строки в соответсвии с изменениями в бд - изменим значения или удалим строку; не найдём индекса с таким ключем и добавим в модель строчку с этим ключем и соответствующими ему данными - куда вставить строку в модели зависит исключительно от реализации: либо вставим её по какому-то признаку сортировки (например, ид по возрастанию), либо уверенные в том, что над моделью сидит прокся, просто добавим строку после всех существующих строк;
в худшем случае мы узнаем лишь в какой таблице произошли изменения и придётся перевыбирать таблицу целиком;
+не стоит забывать, что даже в случае, когда в таблицу пишем мы и точно знаем что и куда пишем, какие-то триггеры могут модифицировать данные в этой же таблице - поэтому в стандартной троллёвской реализации после отправки изменений в бд модель перевыбирается полностью;
конечный пользователь вносит изменения в модель ( и посредством модели - в источник) _только_ через представление - будь то тэйблвью или группа самописных виджетов; и чем меньше в публичном апи модели отступлений от апи абстрактной модели, тем лучше (причин множество)...

а что мешает спросить "второй интерфейс, через который она их (данные) получает" доступен ли сервер, есть ли место на винте и др., и пр. _до_ того, как позвать beginInsertRows ? я вижу только одну причину - это когда "второй интерфейс" сам не знает о всех этих засадах, пока не попробует записать данные. тогда настаёт вопрос о "черезжопности" написания этого-самого "второго интерфейса", который в частном случае может быть сторонним и с закрытым кодом...но и тут можно _сначала_ записать данные во "второй интерфейс", а лишь при успешной записи звать beginInsertRows

пришлось перечитывать тему, т.к. уже ни черта не помню (кому на что отвечал и кому так и забыл ответить)

1. для такого простого случая я бы хранил хэш (источник) приватом в модели
2. под «_только_ через представление» я не имел в виду Q*View (возможно, я путанно изъяснился, но перечитывать снова лениво). важный пункт - все манипуляции с данными моделями _очень и очень_ желательно организовывать через абстрактный интерфейс модели. редко когда требуется нечто странное с извращениями...и чаще это от дефицита мозга. для нашего конкретного примера вариантов больше одного...
3. ...самым простым мне представляется вариант с диалогом добавления/редактирования записи: если требуется отредактировать запись, то данные из текущей строки (model::data(...)) переносим на виджеты новоиспечённого диалога (для простейшего случая можно просто воспользоваться сеттерами соответствующих виджетов-редакторов), а по завершении редактирования валидируем данные и возвращаем в модель (model::setData(...)); при добавлении данных лишь валидируем данные по окончании редактирования и возвращаем их в модель, предварительно создав строку посредством insertRows (т.к. в данном случае валидация уже прошла и мы уверены в корректности, уникальности и т.п. данных). вставлять строку можно до/после текущей строки или в начало/конец списке - в зависимости от требований

insertRows нужен! - это стандартная интерфейсная часть абстрактной модели. документация призывает не забывать об insertRows в кастомных моделях - документация не врёт (обычно)


попросту говоря, item-based модель, это модель, в которой работа с индексами частично или полностью завуалирована работой с айтемами. айтемом может служить указатель на объект, структура, цифробуквенный шифр - в зависимости от задачи и фантазии.

> Подумал, что если тему раскрыть...
пожалуйста, я не против ) копирайтов на свои посты не накладываю

по моему скромному мнению кутэ чудно обходится и без контроллеров.

валидация:
упущен важный момент - QAbstractItemModel::match(...)

insertRows:
между beginInsertRows и endInsertRows можно ничего не делать. это всего лишь необходимые звенья в цепи уведомлений об изменении данных. в сложных моделях, критичных к производительности между beginInsertRows и endInsertRows выполняется работа с источником, т.к. между данными звеньями перевыборки данных и т.п. гарантированно не будет.
чтобы было более понятно, поясню на простом примере:
после endInsertRows вьюхи смогут работать с целой строкой данных, тогда как setData(...) уведомит об обновлении только одной ячейки данных

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

советую почитать исходники QStringListModel - хоть и не совсем то, что нужно, но тепло...

меня этот тред начинает утомлять...

запретить перевыборку нельзя - вьюха не спрашивает у модели готова ли модель отдать данные - если модель заявляет, что имеет 2 столбца и 3 строки, должны быть доступны данные для каждой из 6 ячеек (плюс 5 ячеек вертикального и горизонтального заголовков). чтобы подсказать вьюхе не делать запросы данных, нужно использовать стандартный механизм - layoutAboutToBeChanged()/layoutChanged(), rowsAboutToBeInserted()/rowsInserted() и т.д.

> void MyModel::insertMyRow(const QString& key, const MyData& data)
да, это нестандартный интерфейс. я специально назвал это примером. если читать этот пример, не выдирая его из контекста, это пример оптимизированной вставки данных.
такой конструкцией я пользуюсь, когда необходимо заполнить модель из кэша - не вставлять же данные поиндексно, если после endInsertRows всё-равно произойдёт выборка всех данных для новых строк! и строк там обычно куда более одной.

> Как это сделать? В чем будет выражаться отличие от навигации по индексу?
смотреть документацию и код любой item-based модели...

QStandardItemModel, например