Great work... one question.

The alpha package's bin directory has 36 class libraries in it compared to the previous version that had more like 4. Any chance of getting a guide on which NHibernate assemblies we need to add references to for what, and are all of the 3rd party assemblies in the bin directory needed?

Thanks.

Just reference NHibernate.dll. I'll add a JIRA task to create a description of what is what in there.

Thanks for work.

ReflectHelper.cs, line 270: returns null if mapped clsss has constructor with args but has no no-args constructor. Possibly bug?

270: ConstructorInfo constructor = type.GetConstructor( ReflectHelper.AnyVisibilityInstance, null, CallingConventions.HasThis, NoClasses, null);

Hmm, I'll look into it. It's not a bug, you have to have a no-argument constructor for NHibernate to work, but the function could be written better.

Yes, it should work.

So I'm guessing "default-lazy" in the hibernate-mapping sets the default value for both the entities and collections in that mapping file? That's something new with 1.2 right? If so, would it be possible to get that split out into one default for entities and one for collections, or maybe have it as an enum instead of a boolean?

default-lazy="All | Entities | Collections | None"

Why?

Well, in general I don't like lazy entities because I don't like having to mark all of my properties as virtual. The purist in me finds it offensive (I understand it's necessary) but marking collections as lazy only affects the containers which I'm cool with.

Does that make sense? I dunno, maybe this is an odd request, I just assumed at least a handful of others out there would feel the same.

I'm tantalized by the prospect of user-defined collections. I assume this means that I can specify a custom type for my collections that implements IList, ISet, etc and it will be dynamically proxied to support lazy loading.

If this is the case though I can't find any documentation or example of actually using the feature. Does it have to do with the collection-type property? Do all method implementations of the interface have to be virtual? How does it work exactly?

I'm not an expert on the internals of NHibernate, but, does NHibernate actually proxy collection classes? i.e. generate IL on the fly. I noticed in the source code that there are NHibernate specific collection classes. So, my assumption was that when reading objects out of the database, it would just use the NHibernate collection classes that correspond to whatever interface it is that you're using. i.e. if you had an IList, you might assign to it an ArrayList to begin with, but, when you read data out of the database, the IList does not point to an ArrayList and instead just uses the appropriate NHibernate collection class. i.e no runtime IL generation for collections as is done in the case of proxied classes.

I'm not sure how else you would allow for user-defined collections.

By the way, you may be interested by:
Why associations and collections are lazy by default in NHibernate 1.2.0

Sounds great,
Does this version update the log4net library to 1.2.10

Hello Sergey!

Thanks for the great work!

When do you plan to rollout a stable release (estimated) ?

Thank you,
Gerhard

Hi Sergey!
I've just upgraded to nhibernate 1.2.0 alpha,
generics works nice, woo hoo!!!

But I have a problem, please help me!
if I do this:
NHibernate.ISession session = NHibernate.ISession)NHibernateHelper.NHibernateHelper.GetCurrentSession();

MyObject o = session.Load<MyObject>(PK);
///////////////////////////////////////////////////
//NHibernateUtil.Initialize(o.Name);
//NHibernateUtil.Initialize(o.IsActive);
///////////////////////////////////////////////////

session.Flush();

NHibernateHelper.NHibernateHelper.CloseSession();

return o;

I get a lazy loading error on the fields o.Name and o.IsActive!!

If I NHibernateUtil.Initialize(o.Name), I can access this field!!

It's the default behaviour???
How can I specify this lazy="false" in the mapping property??


Thanks!