nHibernate 3.0.0.4000 по-разному обрабатывает bools в запросах?

Question

Я только что обновил nHibernate с версии 3.0.0.1002 до 3.0.0.4000.Как только я это сделал, многие из моих запросов перестали работать.Один из таких запросов:

var items = (from b in session.Query<InvoiceDetail>() 
                            where b.Customer == AddressedToCustomer && b.IsCreditNote == !addInvoices 
                            orderby b.DueDate , b.InvoiceNumber 
                            select b).ToList(); 

SQL, созданный в 3.0.0.1002:

2011-02-17 15: 55: 43 612 DEBUG выберите invoicedet0_.Id as Id3_, invoicedet0_.InvoiceNumber, как InvoiceN2_3_, invoicedet0_.DocumentNumber как Document3_3_, invoicedet0_.DocumentDate как Document4_3_, invoicedet0_.DueDate как DueDate3_, invoicedet0_.DivisionDetails как Division6_3_, invoicedet0_.IsInvoice как IsInvoice3_, invoicedet0_.IsCreditNote как IsCredit8_3_, invoicedet0_.OriginalAmount как Original9_3_, invoicedet0_.Amountв Amount3_, invoicedet0_.LRNo как LRNo3_, invoicedet0_.LRDate как LRDate3_, invoicedet0_.DispatchedBy как Dispatc13_3_, invoicedet0_.CreditDays как CreditDays3_, invoicedet0_.CustomerId в CustomerId3_ из Детали_Счетов invoicedet0_ где ((invoicedet0_.CustomerId равно нулю) и (@ p0 равна нулю) или invoicedet0_.CustomerId=@p0) и случай, когда invoicedet0_.IsCreditNote = 1, затем 1 else 0 end = случай, когда @ p1 = 1, затем 1 else 0, конечный порядок по invoicedet0_.DueDate asc, invoicedet0_.InvoiceNumber asc; @ p0= 101790 [Тип: Int32 (0)], @ p1 = False [Тип: Int32 (0)]

SQL, созданный в 3.0.0.4000:

2011-02-17 16: 22: 15,275 DEBUG выберите invoicedet0_.Id в качестве Id3_, invoicedet0_.InvoiceNumber в качестве InvoiceN2_3_, invoicedet0_.DocumentNumber в качестве Document3_3_, invoicedet0_.DocumentDate в качестве Document4_3__объектаIsInvoice3_, invoicedet0_.IsCreditNote, как IsCredit8_3_, invoicedet0_.OriginalAmount как Original9_3_, invoicedet0_.Amount как Amount3_, invoicedet0_.LRNo как LRNo3_, invoicedet0_.LRDate как LRDate3_, invoicedet0_.DispatchedBy как Dispatc13_3_, invoicedet0_.CreditDays как CreditDays3_, invoicedet0_.CustomerId как CustomerId3_ изInvoiceDetails invoicedet0_, где invoicedet0_.CustomerId=@p0 и случай, когда invoicedet0_.IsCreditNote = 1, тогда «true», иначе «false» end = случай, когда @ p1 = 'true' then 'true' иначе 'false' конечный порядок по invoicedet0_.DueDate asc, invoicedet0_.InvoiceNumber asc; @ p0 = 101790 [Тип: Int32 (0)], @ p1 = 'False' [Тип: String (0)]

Я использую соглашение для преобразования bools в целые числа (true= 1, ложь = 0).Предыдущая версия делает это преобразование, новая версия - нет.Bool преобразуется в строку в более новой версии, но его следует преобразовать в int в соответствии с соглашением.

Из сгенерированного SQL:«! addInvoices» передается как строка в запросе sql и int в предыдущей версии:3.0.0.1002: @ p1 = True [Тип: Int32 (0)]3.0.0.4000: @ p1 = 'True' [Тип: Строка (0)]

Кроме того, поле базы данных IsCreditNote сравнивается с 'true' и 'false' в новой версии и с 1 и 0 в предыдущей версии.

Во-вторых, даже если я удаляюусловно, это вывод для двух разных команд в 3.0.0.4000:Вставить:

2011-02-20 10: 18: 22,977 ВСТАВКА ОТЛАДКИ В INTOiceDetails (InvoiceNumber, DocumentNumber, DocumentDate, DueDate, DivisionDetails, IsInvoice, IsCreditNote, OriginalAmount, Amount, LRNo, LRDate, Dispatched)CreditDays, CustomerId) VALUES (@ p0, @ p1, @ p2, @ p3, @ p4, @ p5, @ p6, @ p7, @ p8, @ p9, @ p10, @ p11, @ p12, @ p13);выберите last_insert_rowid (); @ p0 = 9070183358 [Тип: Int64 (0)], @ p1 = 28592879 [Тип: Int64 (0)], @ p2 = '20110210' [Тип: String (0)], @ p3 = '20110303 '[Тип: String (0)], @ p4 = NULL [Тип: String (0)], @ p5 = True [Тип: Boolean (0)], @ p6 = False [Тип: Boolean (0)],@ p7 = 2685 [Тип: десятичная (0)], @ p8 = 2685 [Тип: десятичная (0)], @ p9 = NULL [Тип: строка (0)], @ p10 = NULL [Тип: строка (0)], @ p11 = NULL [Тип: строка (0)], @ p12 = 21 [Тип: Int32 (0)], @ p13 = 101760[Тип: Int32 (0)]

Обновление:

2011-02-20 10: 10: 13,941 DEBUG выберите invoicedet0_.Id в качестве Id3_, invoicedet0_.InvoiceNumber asInvoiceN2_3_, invoicedet0_.DocumentNumber, как Document3_3_, invoicedet0_.DocumentDate как Document4_3_, invoicedet0_.DueDate как DueDate3_, invoicedet0_.DivisionDetails как Division6_3_, invoicedet0_.IsInvoice как IsInvoice3_, invoicedet0_.IsCreditNote как IsCredit8_3_, invoicedet0_.OriginalAmount как Original9_3_, invoicedet0_.Amount как Amount3_,invoicedet0_.LRNo, как LRNo3_, invoicedet0_.LRDate как LRDate3_, invoicedet0_.DispatchedBy как Dispatc13_3_, invoicedet0_.CreditDays как CreditDays3_, invoicedet0_.CustomerId как CustomerId3_ из Детали_Счетов invoicedet0_, где invoicedet0_.CustomerId=@p0 и случай, когда invoicedet0_.IsCreditNote = 1, то «истинный'else' false 'end = случай, когда @ p1 =' true ', затем' true 'иначе' false 'конечный порядок по invoicedet0_.DueDate asc, invoicedet0_.InvoiceNumber asc; @ p0 = 107233 [Тип: Int32 (0)], @p1 = 'True' [Тип: Строка (0)]

В Inserts переданный параметр является логическим (@ p6), а в Select - параметром String (@ p1).

Дело в том, что я опубликовал это как проблему на nHibernate JIRA (на самом деле большая часть этого скопирована из этой ветки проблемы), но Патрик Эрл закрыл проблему как проблему.Он сказал, что это стандартное поведение.

Все версии nHibernate до этой версии вели себя правильно.Только этот ведет себя по-другому.Кто-нибудь может прокомментировать, действительно ли это ошибка, или Патрик прав, и мне нужно обойти эту проблему в моей базе данных?

РЕДАКТИРОВАТЬ: Моя база данных SQLite, и я использую Fluent nHibernate.

Answer 1

Филл прав. У поставщика Query / LINQ есть проблемы.

Этот Criteria / QueryOver API работает отлично:

var items = session.QueryOver<InvoiceDetail>()
        .Where(i => i.Customer == AddressedToCustomer)
        .And(i => i.IsCreditNote != addInvoices)
        .OrderBy(i => i.DueDate).Asc
        .ThenBy(i => i.InvoiceNumber).Asc
        .List();

И еще более удивительным является то, что разработчики провайдера просто закрывают проблемы / ошибки как не связанные с проблемами, даже не рассматривая их должным образом. Я планирую заменить все звонки Query<> на звонки QueryOver<>, чтобы быть уверенным. Для такого проекта, как nHibernate, это действительно жаль, особенно если учесть разработчиков, таких как я, которые любят linq.

Answer 2

Некоторые идеи:

Если вы используете сервер SQL, измените тип столбца на бит для логических значений.

Попробуйте подстановки запросов:

3.5.4. Query Language Substitution

You may define new NHibernate query tokens using query.substitutions. For example:
query.substitutions true=1, false=0
would cause the tokens true and false to be translated to integer literals in the generated SQL.
query.substitutions toLowercase=LOWER
would allow you to rename the SQL LOWER function.