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