кастинг строки к bool, использующему nHibernate Критерии
У меня есть запрос nHibernate с помощью Критериев, и я пытаюсь бросить строку к bool в самом запросе. Я сделал то же с кастингом строки к интервалу, и это работает хорошо (свойство "DataField" равняется "1" как строке):
var result = Session
.CreateCriteria<Car>()
.Add(Restrictions.Eq((Projections.Cast(NHibernateUtil.Int32,
Projections.Property("DataField"), 1))
.List<Car>();
tx.Commit();
Но я пытаюсь сделать то же с bool, но я не получаю ожидаемый результат:
var result = Session
.CreateCriteria<Car>()
.Add(Restrictions.Eq((Projections.Cast(NHibernateUtil.bool,
Projections.Property("DataField"), true))
.List<Car>();
tx.Commit();
"Поле данных" является "Верной" строкой, но результат в пустом списке, где это должно содержать 100 элементов со строковым набором свойства "DataField" к "Истинному". Я попробовал "верной" строкой, и "1", но результатом является все еще пустой Список.
[Править]
Как Прокомментировано ниже, я мог проверить на строку, "Верную" или "Ложную", но я скажу, что это - более общий вопрос, чем только для булевской переменной.
Обратите внимание, что идея состоит в том, чтобы иметь своего рода представление значения ключа данных, где значение может быть различными типами данных. Мне нужна таблица значений для содержания всех данных, таким образом храня данные, поскольку строка походит на самое чистое решение!
Я смог использовать метод выше для хранения и интервала и дважды как строки, и броску в запросе, но я не следовал за использованием того же метода для DateDime и булевской переменной.
И для DateTime крайне важно сделать, чтобы фактический DateTime возразил.
Как я могу сделать бросок от строки до bool и представить в виде строки к работе DateTime в запросах?
Спасибо
1 ответ
К сожалению, то, чего вы пытаетесь достичь, будет трудно сделать, потому что это идет вразрез с тем, что nHibernate и RDBM пытаются сделать для вас. Используя нетипизированные данные, вы лишаетесь многих преимуществ, которые дает использование RDBMs.
Не имея полной схемы, я могу только догадываться. Откуда вы знаете, какой тип поля является правильным? Я предполагаю, что у вас есть столбец 'type', который указывает, является ли значение целым, булевым, датой и т.д. Если да, то продолжайте со столбца идентификатора типа, плюс отдельный столбец для каждого типа данных. Это не сложнее, чем то, что вы делаете, поскольку для каждого типа данных уже есть отдельные запросы, и вы получаете ясность, проверку типов и возможность индексирования.
Если вы хотите защититься от возможности определения более чем одного значения (т.е. значений в столбцах нескольких типов), вы можете создать ограничение на таблицу, которое проверяет, что каждая строка определяет значение только для одного типа данных. (Вы также можете проверить, что столбец для указанного типа не является нулевым, если это подходит для вашего случая.)
Альтернативно, вы можете поручить nHibernate управление различными типами и позволить ему сделать всю тяжелую работу за вас. nHibernate может отображать иерархии классов на таблицы, поэтому вы можете создавать сущности, подобные этой:
public class AbstractProperty
{
// concrete name - persisted
public String Name { get; set; etc.. }
// owner property as well?
// abstract value provided by subclasses. This property is not persisted.
// used simply to provide polymorphic access to the value.
public abstract Object Value { get; set; }
}
public class DateProperty : AbstractProperty
{
// concrete date property
public Date date { get; set; etc.. }
// value delegates to date property
public Object value { get; set; }
}
При такой схеме у вас есть возможность получать значения с определенным типом данных, где, например, запрос, использующий сущность DateProperty, явно возвращает экземпляры DateProperty. Вы также можете писать запросы, которые могут возвращать несколько типов, где статическим типом является AbstractProperty. Затем вы можете использовать шаблон посетителя или проверку 'is' на AbstractProperty для определения типа и приведения к конкретному типу для получения значения.
Гуру nHibernate может помочь вам исправить приведение, но в конечном итоге я рекомендую использовать реальные типы данных в вашей базе данных. Это избавит вас от головной боли в дальнейшем.