QSqlRelation вынос мозга

Что не то с QSqlRelation? Разработчики Qt 4.8.1 через QSqlRelation предоставили доступ к текстовой замене поля внешней связи, но не предоставили доступ к реальному int id значению, связываемой таблицы.

Когда возникают неудобства со штатным QSqlRelationalTableModel? Например при копировании строки в таблице QSqlRelationalTableModel.

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

Если есть поле с QSqlRelation, то вызывая для него data() мы сможем получить только его текстовое значение, а нам для копирования надо знать и устанавливать именно int id этого поля для новой копии строки.

Кстати устанавливается int id через QSQlTableModel::setData без проблем.

А вот прочитать int id из QSqlRelationalTableModel никак не получается.

Сначала напрашивается вариант: получить id значение связываемого поля через отдельный запрос QSqlQuery для текущей строки. То есть предварительно надо делать SELECT для текущей строки.

И далее через setData установить значение id для копии строки уже не проблема.
При создании setRelation в недрах исходников происходит заполнение массива QHash int,QString данными из связываемой таблицы. Находится этот массив в QRelation и называется dictionary. И добраться до него из кода никак не получается ни наследованием, никак кроме варианта - исправлять исходники Qt. Как улучшить QSqlRelationalTableModel

Но даже когда вы доберетесь до dictionary и сможете с ним делать все что угодно окажется, что dictionary НИГДЕ НЕ ИСПОЛЬЗУЕТСЯ! То есть dictionary заполняется через отдельный select запрос (populateDictionary) и далее никогда не вычитывается... Поначалу были сомнения, что это так, но после детального изучения кода сомнения на 99% ушли.

К тому же через populateDictionary dictionary заполняется глобально, то есть идет запрос ко всем записям из внешней таблицы. А нам это не нужно, нам надо только к тем кто у нас в таблице присутствует.

По логике, чтобы нагружать базу запросами по минимуму логичнее делать запрос с
LEFT JOIN (к внешней таблице), то есть объединить все в одном запросе. Тогда dictionary вообще не нужен будет.

Осталась убежденность, что QSqlRelationalTableModel подлежит срочному исправлению.

Как улучшить QSqlRelationalTableModel

Тема изучена в лайфхак SqlRelationalTableModel.