NHibernate, устаревшая база данных, внешние ключи, которые не являются

Question

В проекте, над которым я работаю, имеется устаревшая база данных с большим количеством информации, которая используется для изменения поведения приложения. По сути, я застрял с чем-то, что я должен быть супер осторожным с изменением.

На мою проблему. В этой базе данных есть таблица, а в этой таблице - столбец. Этот столбец содержит целые числа, и большинство ранее существующих данных имеют значение ноль для этого столбца.

Проблема в том, что этот столбец на самом деле является ссылкой внешнего ключа на другой объект, просто он никогда не определялся как таковой в схеме базы данных.

Теперь в моем новом коде я определил свое отображение Fluent-NHibernate для обработки этого столбца как ссылки, чтобы мне не приходилось иметь дело с идентификаторами сущностей непосредственно в моем коде. Это работает нормально, пока я не наткнусь на сущность со значением 0 в этом столбце.

NHibernate считает, что значение 0 является допустимой ссылкой. Когда мой код пытается использовать этот объект, на который ссылаются, я получаю исключение ObjectNotFoundException, так как очевидно, что в моей базе данных нет объекта с идентификатором 0.

Как я могу, с помощью сопоставления или какого-то соглашения (я использую Fluent-nhibernate), получить NHibernate для обработки идентификаторов, которые равны 0, как если бы это было NULL?

Answer 1

Я обнаружил, что API сообщает NHibernate игнорировать ссылки, которые не найдены (NotFound.Ignore ()), а не генерировать исключение. Я был смущен всеми упоминаниями SetAttribute (), которые я нашел в Интернете, для более старой версии fluent-nhibernate, чем я использую.

Answer 2

Я в такой же ситуации. Проблема с not-found = ignore заключается в том, что он будет запрашивать отношение каждый раз, когда вы пытаетесь получить к нему доступ, даже если оно уже было выполнено в исходном запросе. По сути, Hibernate не хранит факт, что нет записи для другой стороны отношений. Вы можете увидеть это в действии в журнале отладки. Вот пример из моего текущего проекта.

loading entity:
attempting to resolve:
object not resolved in any cache:
Fetching entity:
loading entity:
Opened new IDbCommand, open IDbCommands: 1
Building an IDbCommand object for the SqlString: SELECT townshipdo0_.TOWNSHIP_CODE as TOWNSHIP1_203_0_, townshipdo0_.TOWNSHIP_NAME as TOWNSHIP2_203_0_, townshipdo0_.TOWNSHIP_TYPE_CODE as TOWNSHIP3_203_0_, townshipdo0_.TOWN_ACTIVE_FLAG as TOWN4_203_0_, townshipdo0_.VERS as VERS203_0_ FROM VTTOW_TOWN_CODE townshipdo0_ WHERE townshipdo0_.TOWNSHIP_CODE=?
binding ' ' to parameter: 0
SELECT townshipdo0_.TOWNSHIP_CODE as TOWNSHIP1_203_0_, townshipdo0_.TOWNSHIP_NAME as TOWNSHIP2_203_0_, townshipdo0_.TOWNSHIP_TYPE_CODE as TOWNSHIP3_203_0_, townshipdo0_.TOWN_ACTIVE_FLAG as TOWN4_203_0_, townshipdo0_.VERS as VERS203_0_ FROM VTTOW_TOWN_CODE townshipdo0_ WHERE townshipdo0_.TOWNSHIP_CODE=:p0

Вы можете видеть, как он пытается связать '', БД для этого приложения использует пустое пространство для представления нуля (глупо, я знаю). Но каждый раз, когда nhibernate сталкивается с этим, он пытается найти его из БД, потому что он не может найти запись в кеше и не знает, что это на самом деле NULL.

Было бы неплохо, если бы мы могли указать нулевое значение по умолчанию, которое будет игнорироваться в конфигурации. В настоящее время единственный способ обойти это - использовать запросы для загрузки ваших отношений, а не полагаться на запросы, сгенерированные nhibernate.