За ответ на предыдущий вопрос (ответ здесь: Представления SQL / базы данных в Grails), Я попытался использовать класс предметной области для представления представления в моей базе данных. Однако в большинстве случаев это прекрасно работает:
У меня представление без единого уникального ключа. Скажем, базовые таблицы выглядят так:
A:
id, varX
1, "Blah"
2, "Foo"
3, "Bar"
B:
id,A.id,C.id
1,2,1
2,2,2
3,3,1
C:
id, varY
1, "Boom"
2, "Fizzle"
Мое представление выглядит так:
A.id, varX, B.id, C.id, varY
1, "Blah", NULL, NULL, NULL
2, "Foo", 1,1, «Бум»
2, «Фу», 2,2, «Шип»
3, «Бар», 3,1, «Бум»
Именно так это должно выглядеть для наших целей. Однако, как вы можете видеть, лучший уникальный составной идентификатор, который мы могли бы создать для представления, - это ['A.id', 'C.id'], поскольку он однозначно идентифицирует каждый элемент, но Grails терпит неудачу, потому что не может иметь дело с часть составного идентификатора имеет значение NULL (фактически, list () возвращает список из 4 объектов, первый из которых является нулевым указателем, остальные являются фактическими экземплярами домена представления).
Обратите внимание, что мы также можем использовать A.id и B.id, но у них та же проблема.
Также обратите внимание, что мы ХОТИМ отображать элементы из таблицы A хотя бы один раз (с нулевыми значениями для любых полей, не найденных в таблицах B / C), возможно, много раз, если есть несколько соответствующих записей в таблице B.
Итак, мой вопрос состоит из двух частей:
1: можно ли вообще определить класс домена grails без какого-либо поля идентификатора? Нам не нужен постоянный дескриптор для какой-либо из записей представлений, нам просто нужно перечислить данные в этом представлении.
2: Если нет, можно ли определить класс домена grails с полем составного идентификатора, часть из которых может быть NULL, но который в любом случае будет однозначно идентифицировать строку, даже если часть составного идентификатора равна NULL?
Я знаю, что мы можем использовать прямой Groovy SQL для запроса представления напрямую без ассоциированного класса домена (на самом деле мы делаем это сейчас), но в идеале мы хотели бы представить представление с помощью класса предметной области. Кроме того, если отбросить все аргументы, эти два вопроса могут быть применены в гораздо более общем смысле, чем просто к нашей конкретной проблеме.
