JPA Query возвращает nulls - Composite Key с нулевым столбцом

Question

У меня есть устаревшая база данных (фактически файлы Cobol), к которой я обращаюсь, используя запатентованный JDBC-драйвер с Hibernate/JPA.

Объект имеет составной первичный ключ с 2 столбцами: CODE и SITE.

В унаследованных данных имеются записи для одной и той же CODE, которые могут иметь либо конкретное значение для SITE, или может быть запись с NULL в SITE столбце, который представляет «Все сайты». Теория этого файла, если вы не можете найти CODE для своего конкретного SITE, то вы просматриваете запись с помощью NULL в SITE («catch-all»).

Я не могу изменить структуру этой «таблицы», поскольку это потребует перезаписи больших частей старой системы Cobol, которую мы не хотим делать. Я также не могу создавать представления данных.

Теперь, когда я делаю em.find с первичным ключом класса композит, содержащий конкретный code и нуль для site, то Hibernate правильно находит запись соответствия со значением NULL в столбце - Все хорошо!

Но если я пытаюсь сделать запрос, используя em.createQuery, подобный следующему:

SELECT x FROM TareWeight x WHERE x.pk.code = 'LC2' 

, для которых есть 2 записей, она возвращает пустой объект в результирующий список для записи с NULL в SITE column.

Если я беру SQL, который Hibernate использует для этого запроса, тогда «база данных» возвращает две записи: одну с сайтом NULL и одну с определенным сайтом. Похоже, что когда Hibernate загружает Entities из этих результатов, он сопоставляет его с нулевым объектом Entity.

Так что либо Hibernate поддерживает его, либо нет. Почему бы работать em.find, но не em.createQuery?

Я знаю, что this question аналогичен, но ответы, похоже, предполагают, что это невозможно. Но ясно, что Hibernate может правильно найти, так почему запрос не работает?

---

EDIT: ОК, так что я нашел определение в NullableStringType класс на this Hibernate JIRA Issue и добавить его в мой проект.

Если добавить @Type определения на site колонки ПК с помощью этого класса типа, то я могу успешно получить ненулевые Сущности назад от SELECT, запроса, с site поля, содержащего все, что строка текстом я определяю как представление от null.

Однако он по-прежнему ведет себя по-другому. find возвращает объект с полем site, содержащим null, но запрос возвращает объект с полем site, содержащим «NaN» (представление по умолчанию null).

По-прежнему кажется, что они должны вести себя одинаково.

---

UPDATE 2: Некоторые из вас хотят знать особенности о «базе данных» в вопросе.

Это движок Genesis RDBMS, написанный Trifox Inc.. Данные хранятся в файлах AcuCobol (теперь Micro Focus) Vision.

У нас есть набор настроек для перевода пустых (SPACES) буквенно-цифровых полей в NULL, поэтому наши записи файлов, содержащие пробелы для поля PK, переводятся в NULL. Я могу специально выбрать соответствующую запись, используя WHERE site_id IS NULL, поэтому RDBMS обрабатывает эти пустые поля как SQL NULL.

Сказав все, что я не верю, что эта проблема имеет какое-либо отношение к «базе данных», помимо того факта, что необычные поля PK являются нулевыми.

Более того, если я зарегистрирую SQL, который Hibernate использует как для find, так и для запроса, они почти идентичны.

Вот SQL для находки:

select tareweight0_.CODE as CODE274_0_, tareweight0_.SITE as SITE274_0_, 
     tareweight0_.WEIGHT as WEIGHT274_0_ from TARE_WEIGHT tareweight0_ 
     where tareweight0_.CODE=? and tareweight0_.SITE=? 

И вот SQL для запроса:

select tareweight0_.CODE as CODE274_, tareweight0_.SITE as SITE274_, 
     tareweight0_.WEIGHT as WEIGHT274_ from TARE_WEIGHT tareweight0_ 
     where tareweight0_.CODE=? and tareweight0_.SITE=? 

Как вы можете видеть, единственное различие в названиях столбца псевдонимов.

---

UPDATE 3: Вот некоторые примеры данных:

select code, site, weight from tare_weight where code like 'LC%'; 

CODE SITE WEIGHT 
------ ------ ------- 
LC1    .81 
LC2    .83 
LC2 BEENLH  .81 
LC3    1.07 
LC3 BEENLH 1.05 
LC4    1.05 
LCH1    .91 
LCH2    .93 
LCH2 BEENLH  .91 
LCH6    1.13 
LCH6 BEENLH 1.11 

и поиск специально для NULL:

select code, site, weight from tare_weight where code like 'LC%' and site IS NULL; 

CODE SITE WEIGHT 
------ ------ ------- 
LC1    .81 
LC2    .83 
LC3    1.07 
LC4    1.05 
LCH1    .91 
LCH2    .93 
LCH6    1.13 

Answer 1

«Так как они поддерживают его, либо нет "

TL; DR Это ожидание/чувство необоснованно. Неподдерживаемая функциональность в вашей ссылке (& минута) - это именно ваша. «Не поддерживать» означает, что если вы это сделаете, Hibernate сможет делать все, что захочет. Вам повезло, что они (кажется) возвращают разумные ценности. (Хотя это всего лишь догадка, как они действуют. У вас нет спецификации.) Нет причин ожидать чего-либо, не говоря уже о последовательности. Когда поведение является следствием какого-то неподдерживаемого случая, любое «почему» скорее всего является просто артефактом того, как код был написан с учетом других случаев.

---

Вот (п старая) поддержка потоков ответил на Hibernate Team:

Заголовок сообщения: Составной ключ с нулевым значением для одного столбца
PostPosted: пн 3 июля 2006 2:21 утра

у меня есть таблица с составным первичным ключом, и я создал следующие отображения для table.As его можно вставить нулевое значение для любого столбца составного ключа до тех пор, как сочетание все столбцы: Уникальный, у меня есть запись в таблице, которая имеет нулевое значение для столбца V_CHAR2 (который является частью составного ключа). когда я выполняю запрос на этой сущности, я получаю нулевые значения для записей, которые имеют значение значения столбца V_CHAR2. Что плохого в моем картографирования и реализации ..

Добавлено: Вт 11 июля 2006 9:09 утра
Hibernate Team

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

Добавлено: Сб 6 января 2007 5:35 утра
Hibernate Team

Извините, что disapoint вас, но null в первичном ключе не поддерживается - прежде всего потому, что для выполнения объединений и сравнений потребуется много больно глупый код, который просто не нужен нигде ... думаю об этом, и вы будете см. (например, как вы делаете правильно присоединиться такую ​​таблицу)

Это не удивительно, потому что NULL не допускается в колонке ПК в SQL. Объявление PRIMARY KEY является синонимом UNIQUE NOT NULL. NULL ничем не отличается от (ошибочного) намерения, что некоторая незаписанная величина не известна как равная. (Ваши ожидания какого-то исключения по крайней мере в некоторых случаях NULL в PK , равном, NULL в состоянии противоречит SQL.) Учитывая, что NULL не допускается в значениях PK, мы можем ожидать, что оптимизация PK связана с 1 : 1 сопоставления и вместо наборов строк, чтобы предположить, что нет нулей, когда это удобно. Можно ожидать, что Hibernate решила не беспокоиться о том, что их реализация сделала с случаями, которые не должны возникать в SQL. Жаль, что они не говорят вам об этом при компиляции или исполнении. Надеюсь, это указано в документации.)

Даже find отличается от createQuery re NULL неудивительно. Первое включает в себя одно значение, в то время как последнее включает в себя то, что, как ожидается, будет множеством (а не мешками) строк без NULL (но это не так).

Обходным решением может быть не обрабатывать любой столбец первичного ключа как NULL, а как фактическую строку пробелов в памяти. (Независимо от того, что это означает, учитывая ваш стек хранения/СУБД/гибернации/JPA/Java. Вы не предоставили нам достаточно информации, чтобы узнать, будет ли препятствовать вашему представлению Cobol базы данных, если не сопоставить пространства с NULL для вашей JPA). С вашими данными вы можете объявить индекс UNIQUE в столбцах.