nHibernate, неожиданный cast varchar(255)

[ProESM]

Приветствую!

Заметил странное для меня поведение в nHibernate.

Формирую критерию для выполнения запроса. Запрос простой - получить из таблицы записи с Id из списка. Пользуюсь Restrictions.In"/"Restrictions.InG".
Само поле Id у меня имеет тип string (в базе varchar(36)), в нем хранится Guid.

Создаю критерию следующим образом:

...
var criteria = DetachedCriteria.For<TreeDao>();
criteria.Add(Restrictions.InG("Id", new string[] { "c034e889-3b80-42d3-bdad-5f4e729a905b" }));
return DesignerWorkplaceProvider.Current.Session.List<TreeDao>(criteria).ToList();

Класс TreeDao описан так:

public class TreeDao : ITreeDao
    {        
        public virtual IList<TreeParentDao> Parents { get; set; }        
        
        public virtual string Id { get; set; }        
        
        public virtual TreeDao Parent { get; set; }        
        
        public virtual string Name { get; set; }        
        
        public virtual string ShortName { get; set; }        
        
        public virtual TreeDao Type { get; set; }        
        
        public virtual TreeDao State { get; set; }
        
        public virtual DateTime CreateDateTime { get; set; }
    }

Маппинг выглядит так:

public class TreeMap : ClassMap<TreeDao>
    {
        public TreeMap()
        {
            Table("L_TREE");
            Id(x => x.Id)
                .Column("ID")
                .Length(36)                
                .Not.Nullable();

            HasMany(x => x.Parents)
                .KeyColumns.Add("Id", p => p.Name("TREE_CHILD_ID"))
                .Table("L_TREE_PARENTS")
                .LazyLoad()
                .ReadOnly()
                .Cascade.None();

            References(x => x.Parent)
                .Column("PARENT_ID")
                .Nullable();
            Map(x => x.Name)
                .Column("NAME")
                .Length(255)
                .Not.Nullable();
            Map(x => x.ShortName)
                .Column("SHORT_NAME")
                .Length(100)
                .Nullable();
            References(x => x.Type)
                .Column("TYPE_ID")
                .Not.Nullable();
            References(x => x.State)
                .Column("STATE_ID")
                .Not.Nullable();
            Map(x => x.CreateDateTime)
                .Column("CREATE_DATETIME")
                .Not.Nullable();
            Polymorphism.Explicit();
            Cache.ReadWrite();
            DiscriminateSubClassesOnColumn("").Formula("TYPE_ID");
        }
    }

В логах вижу, что программа конвертит передаваемую строку из массива в поле типа varchar(255):

SELECT this_.ID as ID19_0_, this_.NAME as NAME19_0_, this_.SHORT_NAME as SHORT3_19_0_, 
this_.CREATE_DATETIME as CREATE4_19_0_, this_.PARENT_ID as PARENT5_19_0_, this_.TYPE_ID as TYPE6_19_0_,
 this_.STATE_ID as STATE7_19_0_, this_.TYPE_ID as clazz_0_ FROM L_TREE this_ WHERE this_.ID in (cast(@p0 as VARCHAR(255)))

Parameters:
Name:@p0	Type:VarChar	Used Value:c034e889-3b80-42d3-bdad-5f4e729a905b

Не могу понять, с чем это связано?!

Причем если делать обычный условие Equals, то преобразований (cast-oв) нет:

criteria.Add(Restrictions.Eq("Id", "c034e889-3b80-42d3-bdad-5f4e729a905b"));

SELECT this_.ID as ID19_0_, this_.NAME as NAME19_0_, this_.SHORT_NAME as SHORT3_19_0_, 
this_.CREATE_DATETIME as CREATE4_19_0_, this_.PARENT_ID as PARENT5_19_0_, this_.TYPE_ID as TYPE6_19_0_,
 this_.STATE_ID as STATE7_19_0_, this_.TYPE_ID as clazz_0_ FROM L_TREE this_ WHERE this_.ID = @p0
Parameters:
Name:@p0	Type:VarChar	Used Value:c034e889-3b80-42d3-bdad-5f4e729a905b

Помогите, пожалуйста, разобраться.

Заранее спасибо!

[come-on]

выбросить nHibernate как отживший свое время

[ProESM]

Хорошо :-)

А есть варианты с nHibernate? Просто вся система уже настроена через этот фреймворк

[come-on]

Так проблема то в чем? ну конвертит и конвертит, ну и что?
работает же

[ProESM]

Вытекают 2 проблемы/неудобства:
1) увеличивается скорость работы (для каждого элемента пусть и тратится совсем немного времени на его cast, но если элементов много, более 1000, то это уже заметно);
2) cast в varchar(255) при необходимости только в 36 символах удлиняет саму итоговую SQL строку запроса. Пороговое количество элементов, которые можно уместить в одном запросе, уменьшается. Придется дробить на несколько подзапросов и т.п.

Мне сейчас именно поведение непонятно и, как следствие, вопрос - как можно на это повлиять?

[come-on]

для каждого элемента пусть и тратится совсем немного времени на его cast,

разве для каждого?

[ProESM]

Да, к сожалению и моему пока непониманию - да, для каждого элемента из списка, который я подставляю в

criteria.Add(Restrictions.InG("Id", new string[] { "c034e889-3b80-42d3-bdad-5f4e729a905b", 
  "f8984cd8-3409-4c19-8fce-85a5bd2e3161" и т.п. }));

[Пепел Феникса]

Сообщение от come-on

выбросить nHibernate как отживший свое время

и что же сейчас современно по вашему?



ТС, а почему не взят нормальный GUID тип?
а так вам стоит к ним идти и писать об этом, слишком узкое все же.

[ProESM]

База FireBird, по умолчанию нет такого поля :-(

[come-on]

и что же сейчас современно по вашему?

мало разве? линк, ентити, всякие бейз ферст/ласт и т.д.

ТС, а почему не взят нормальный GUID тип?

так у него и так он, вы посмотрите что сейчас пользуют в базах, никакихъ гуидов, варчар и вперед