Работает ли QRelation с полями, где разрешено значение NULL?

[cdsmika]

Столкнулся с проблемой.
Устанавливаю qobject_cast<SqlModel * > (model)->setRelation(index, QSqlRelation(
                     fieldsRecord.value("name_ref_schema").toString() + "." +
                     fieldsRecord.value("name_ref_object").toString(),
                     fieldsRecord.value("actual_name_ref_field").toString(),
                     visFieldName) );
Во-первых, может кто сталкивался, метод из qrelationaltablemodel.cpp
QString QSqlRelationalTableModel::selectStatement() const отказывается работать с указанием связанной таблицы со схемой (через точку). Пришлось скорректировать данную функцию, чтоб заработало.
Во-вторых заметил, что в основной модели отражаются только те записи, в которых присутствуют значения из связанной таблицы, а записи с NULL отбрасываются. Это так и задумано или нет? Что же теперь в каждый справочник нулевое значение вставлять?

[SABROG]

Это так и задумано или нет? Что же теперь в каждый справочник нулевое значение вставлять?

Я тоже с этим столкнулся где-то 2 года назад, тогда я просто отказался от использования QRelation и сделал через QStandardItemModel и отдельных QSqlQuery. Потом я увидел проект на Delphi, который живет около 10 лет, так там, чтобы показать, что элемент ни к чему не привязан первым элементам в ссылающихся таблицах стоит -1, а значением всех полей либо пустые, либо -1. Соответственно во всяких "справочниках", которые отображают содержимое таблиц нигде этого нулевого элемента не видно, чтобы его было невозможно удалить или как-то изменить. При этом элементы, которые ни к чему не привязаны отображаются нормально, просто нужно вокруг всего это написать код, который будет учитывать подобные исключения в номерах ключей.

[Marat(Qt)]

sqlrelationalmodel обеспечивает подстановку, строки, в которые невозможна подстановка - отфильтровываются. Это идеология. Мне кажется это очень правильным. null в месте подстановки быть не должно имхо. Должно быть подставлено значение по умолчанию. Т.е. если человек не задал пол, то пусть будет подстановка фразы "не известен", а не null

[break]

Что же теперь в каждый справочник нулевое значение вставлять?

почему просто не сделать нужный вам столбец NOT NULL, сделать значение по умолчанию действительно 0

Это так и задумано или нет?

конечно задумано потому что запрос с элементарным join будет вести себя также - отбросит поля с NULL


думаю заменять null на -1 неверно т.к. null в реляционных БД означает не заполнено - а -1 это такое же значение как и 1,5,10,100

QString QSqlRelationalTableModel::selectStatement() const отказывается работать с указанием связанной таблицы со схемой (через точку).

Этого я не понял...

[SABROG]

$

думаю заменять null на -1 неверно т.к. null в реляционных БД означает не заполнено - а -1 это такое же значение как и 1,5,10,100

Если речь о primary key, то в нем вроде бы нельзя значение NULL поставить? А в остальных полях - пожалуйста, хоть "Пусто", хоть "Значение не задано", хоть "N/A". Лишь бы юзер понимал.

[break]

Я о том что есть поля которые мы можем определить NOT NULL - и это может быть любое поле не только первичный ключ, а если уж поле может содержать NULL то это должно быть спланировано а не так что из-за недостатков визуальных компонент обходить NULL используя вместо этого -1

[cdsmika]

sqlrelationalmodel обеспечивает подстановку, строки, в которые невозможна подстановка - отфильтровываются. Это идеология. Мне кажется это очень правильным. null в месте подстановки быть не должно имхо. Должно быть подставлено значение по умолчанию. Т.е. если человек не задал пол, то пусть будет подстановка фразы "не известен", а не null

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

[cdsmika]

Это так и задумано или нет? Что же теперь в каждый справочник нулевое значение вставлять?

Я тоже с этим столкнулся где-то 2 года назад, тогда я просто отказался от использования QRelation и сделал через QStandardItemModel и отдельных QSqlQuery. Потом я увидел проект на Delphi, который живет около 10 лет, так там, чтобы показать, что элемент ни к чему не привязан первым элементам в ссылающихся таблицах стоит -1, а значением всех полей либо пустые, либо -1. Соответственно во всяких "справочниках", которые отображают содержимое таблиц нигде этого нулевого элемента не видно, чтобы его было невозможно удалить или как-то изменить. При этом элементы, которые ни к чему не привязаны отображаются нормально, просто нужно вокруг всего это написать код, который будет учитывать подобные исключения в номерах ключей.

-1 подставить не могу, т.к. использую повсеместно (ТЗ) GUID

[cdsmika]

$

думаю заменять null на -1 неверно т.к. null в реляционных БД означает не заполнено - а -1 это такое же значение как и 1,5,10,100

Если речь о primary key, то в нем вроде бы нельзя значение NULL поставить? А в остальных полях - пожалуйста, хоть "Пусто", хоть "Значение не задано", хоть "N/A". Лишь бы юзер понимал.

Причем здесь primary key? Я о foreign key говорю.

[cdsmika]

Что же теперь в каждый справочник нулевое значение вставлять?

почему просто не сделать нужный вам столбец NOT NULL, сделать значение по умолчанию действительно 0

А чем 0 будет отличаться от значения NULL? Его же в справочнике не будет. А добавление в справочник значений типа "не задано" или "пусто" считаю лишним и нецелесообразным. В VCL даже таких заморочек нет (см. DevExpress TcxLookupComboBox)

[cdsmika]

Это так и задумано или нет?

конечно задумано потому что запрос с элементарным join будет вести себя также - отбросит поля с NULL

Ну меня-то left join интересует. Причем здесь это?

[cdsmika]

QString QSqlRelationalTableModel::selectStatement() const отказывается работать с указанием связанной таблицы со схемой (через точку).

Этого я не понял...

А что тут не понятного? Если справочник находится в другой схеме то мы к нему обращаемся public.sl_country. А если в запросе два справочника и у них одинаковые поля, то QSqlRelationalTableModel подставляет им неверные псевдонимы:
relation.tableName() + relation.displayColumn(). И получается запрос типа: SELECT customers .id, public.sl_country.name AS public.sl_country.name FROM customers LEFT JOIN public.sl_country ON customers.id_country = public.sl_country.id. Запрос формируется с ошибкой (багу запостил). Здесь необходимо псевдоним взять в кавычки. Исправил исходник, пересобрал QtSQL4 - теперь работает. Кому интересно могу выслать.

[cdsmika]

sqlrelationalmodel обеспечивает подстановку, строки, в которые невозможна подстановка - отфильтровываются. Это идеология. Мне кажется это очень правильным. null в месте подстановки быть не должно имхо. Должно быть подставлено значение по умолчанию. Т.е. если человек не задал пол, то пусть будет подстановка фразы "не известен", а не null

Поясните идеологию опускания разработчика:
Вот я говорю модели выбери мне вот эти записи. Ставлю ей связь с другой таблицей. А она мне в ответ показывает те записи, значения которых смогла найти в связанной таблице (откуда она знает строгое мне нужно соответствие или нет?) - поди догадайся почему (ни тебе assert'а, ни ошибки, output пустой - вообще ничего)...

[break]

возьми элементарный комбобокс делегат - заведи в нем нужные значения - выбранные из связанной таблицы + пустой QVariant для NULL и все будет работать

[cdsmika]

возьми элементарный комбобокс делегат - заведи в нем нужные значения - выбранные из связанной таблицы + пустой QVariant для NULL и все будет работать

Спасибо за дельный совет. Не пробовал вставлять пустые записи в делегат.
На самом деле и такой подход не является эталоном, т.к. я бы хотел для редактирования выбором из связанной таблицы использовать несколько делегатов (ну к примеру, <10 - QComboBox, >10 Форма с возможностью выбрать из списка и отфильтровать записи) для юзверского удобства так скзать. При этом добавлять пустую запись в каждую модель такого делегата - на мой взгляд не совсем удобный подход. Другое дело, если бы существовали методы указания QRelation типа связи (строгое/нестрого соответствие).