Explore topic-wise InterviewSolutions in .

This generally happens when NHibernate can't figure out which items changed in the collection. Common causes are:

• replacing a persistent collection entirely with a new collection INSTANCE
• passing NHibernate a manually constructed object and calling Update on it.
• serializing/deserializing a persistent collection apparently also causes this problem.
• updating a <BAG&GT; with INVERSE="false" - in this case, NHibernate can't construct SQL to update an INDIVIDUAL collection item.

Thus, to avoid the problem:

• pass the same collection instance that you got from NHibernate back to it (not necessarily in the same session),
• try using some other collection instead of <bag> (<idbag> or <set>), or
• try using inverse="true" attribute for <bag>.

This generally happens when NHibernate can't figure out which items changed in the collection. Common causes are:

Thus, to avoid the problem:

This TERM is used in NHibernate to refer to a collection of its internal class (NHibernate.Collections.Set, List, Bag, etc.) which wraps a user's collection. All collections belonging to ENTITIES returned by NHibernate are PERSISTENT (= wrapped). Entities passed to Save also have their collections wrapped and replaced by the WRAPPERS as a part of the saving process. Persistent collections have a snapshot of their original state and can therefore be updated more efficiently.

Collections containing query results are not persistent, they are plain .NET collections (=ArrayList=s).

This term is used in NHibernate to refer to a collection of its internal class (NHibernate.Collections.Set, List, Bag, etc.) which wraps a user's collection. All collections belonging to entities returned by NHibernate are persistent (= wrapped). Entities passed to Save also have their collections wrapped and replaced by the wrappers as a part of the saving process. Persistent collections have a snapshot of their original state and can therefore be updated more efficiently.

Collections containing query results are not persistent, they are plain .NET collections (=ArrayList=s).

The names of the collection mappings is one obvious place where the differences between Java and .NET are shown. Java's collection library has many more options than System.Collection does.

• The <list> MAPS directly to an IList.
• The <map> maps directly to an IDictionary.
• The <bag> maps to an IList. A <bag> does not completely comply with the IList interface because the ADD() method is not guaranteed to return the correct index. An object can be added to a <bag> without INITIALIZING the IList. Make sure to either hide the IList from the consumers of your API or make it well documented.
• The <set> maps to an Iesi.Collections.ISet. That interface is part of the Iesi.Collections assembly distributed with NHIBERNATE.

If an order-by attribute is added to the collection mapping element then the concrete collection type will change to one that supports maintaining the order an element was added. For a <bag> it still uses an ArrayList. For the <map> and <set> that have an order-by attribute the concrete collection class changes to a Specialized.ListDictionary and Iesi.Collections.ListSet, respectively. This should be a non-issue since the consumers of your API are using the interfaces IList and Iesi.Collections.ISet.

If a SORT attribute is added to the collection mapping element then the concrete collection type will change to one that supports ordering. For the <map> and <set> that have a sort attribute the concrete collection class changes to a SortedList or Iesi.Collections.SortedSet, respectively, that uses the IComparer provided in the sort attribute. This should be a non-issue to the consumers of your API since they are using the interfaces IList and Iesi.Collections.ISet.

Using an order-by or sort attribute does have implications on performance for maps and sets as the size of the collections grows. Please read the MSDN documentation about the ListDictionary and SortedList performance implications. There are also some good articles on The Code Project about collections.

The names of the collection mappings is one obvious place where the differences between Java and .NET are shown. Java's collection library has many more options than System.Collection does.

If an order-by attribute is added to the collection mapping element then the concrete collection type will change to one that supports maintaining the order an element was added. For a <bag> it still uses an ArrayList. For the <map> and <set> that have an order-by attribute the concrete collection class changes to a Specialized.ListDictionary and Iesi.Collections.ListSet, respectively. This should be a non-issue since the consumers of your API are using the interfaces IList and Iesi.Collections.ISet.

If a sort attribute is added to the collection mapping element then the concrete collection type will change to one that supports ordering. For the <map> and <set> that have a sort attribute the concrete collection class changes to a SortedList or Iesi.Collections.SortedSet, respectively, that uses the IComparer provided in the sort attribute. This should be a non-issue to the consumers of your API since they are using the interfaces IList and Iesi.Collections.ISet.

Using an order-by or sort attribute does have implications on performance for maps and sets as the size of the collections grows. Please read the MSDN documentation about the ListDictionary and SortedList performance implications. There are also some good articles on The Code Project about collections.

No, it does not modify your IL in ANYWAY. Your IL remains exactly as it was when you COMPILED it.

When an object is LOADED by NHibernate the ISession keeps a snapshot of the state of your object. When you FLUSH() the ISession NHibernate compares that snapshot to the current state of the object. The appropriate changes are written to the database.

No, it does not modify your IL in anyway. Your IL remains exactly as it was when you compiled it.

When an object is loaded by NHibernate the ISession keeps a snapshot of the state of your object. When you Flush() the ISession NHibernate compares that snapshot to the current state of the object. The appropriate changes are written to the database.

To be able to create a proxy for a class, the class should have its properties, METHODS and EVENTS declared as virtual. This is not required if the class is PROXIED through an interface it implements (specified using proxy="SomeInterface"). There is no CODE in NHibernate 1.0 to validate your proxy classes, but that will be added in NHibernate 1.1.

NHibernate USES the library Castle.DynamicProxy that is part of the Castle Project. DynamicProxy generates IL - not modifying your IL - at runtime for a subclass of your class, or the IL to implement an interface.

To be able to create a proxy for a class, the class should have its properties, methods and events declared as virtual. This is not required if the class is proxied through an interface it implements (specified using proxy="SomeInterface"). There is no code in NHibernate 1.0 to validate your proxy classes, but that will be added in NHibernate 1.1.

NHibernate uses the library Castle.DynamicProxy that is part of the Castle Project. DynamicProxy generates IL - not modifying your IL - at runtime for a subclass of your class, or the IL to implement an interface.

If you compile the mapping files into an assembly as an /EMBEDDED Resource (my personal recommendation) and you use Visual Studio .NET 2003 for DEVELOPMENT, then you need to REBUILD the project, not just build it if all that was changed is a hbm.xml file. VS.NET will not rebuild a project if only an embedded resource has changed - so the assembly STILL contains the OLD hbm.xml file.

If you compile the mapping files into an assembly as an /Embedded Resource (my personal recommendation) and you use Visual Studio .NET 2003 for development, then you need to rebuild the project, not just build it if all that was changed is a hbm.xml file. VS.NET will not rebuild a project if only an embedded resource has changed - so the assembly still contains the old hbm.xml file.

This often happens when there is a typo in a mapping file, or when you FORGET to SET the BUILD action for the file to Embedded RESOURCE in VISUAL Studio .NET.

This often happens when there is a typo in a mapping file, or when you forget to set the build action for the file to Embedded Resource in Visual Studio .NET.

NHIBERNATE 1.0 is a port of HIBERNATE 2.1. Some obscure features of Hibernate 2.1 are missing from NHibernate and a few SIMPLE features from Hibernate 3 are PRESENT. 

NHibernate 1.0 is a port of Hibernate 2.1. Some obscure features of Hibernate 2.1 are missing from NHibernate and a few simple features from Hibernate 3 are present. 

you can use the following CODE:

IFrameworkEnvironment FE = NEW BurrowFramework().BurrowEnvironment; 

NHibernate.Cfg.Configuration cfg = fe.GetNHConfig("PersistenceUnit1"); 

...

//do WHATEVER change you need to cfg 

fe.RebuildSessionFactories(); 

you can use the following code:

IFrameworkEnvironment fe = new BurrowFramework().BurrowEnvironment; 

NHibernate.Cfg.Configuration cfg = fe.GetNHConfig("PersistenceUnit1"); 

...

//do whatever change you need to cfg 

fe.RebuildSessionFactories(); 

Some existing OpenSessionPerView supporting HttpModule SOLUTIONS CREATE UNNECESSARY session and transaction for every http request including REQUESTS for digital assets such as PICTURE and css file. NHibernate.Burrow only creates session and transaction for http request handler that needs.

Some existing OpenSessionPerView supporting HttpModule solutions create unnecessary session and transaction for every http request including requests for digital assets such as picture and css file. NHibernate.Burrow only creates session and transaction for http request handler that needs.

NHibernate.Burrow CURRENTLY only WORKS in .NET FRAMEWORK 2.0

NHibernate.Burrow currently only works in .Net Framework 2.0

BURROW 1.0 ALPHA 1 is USING NHIBERNATE 2.0 Alpha 1.

Burrow 1.0 alpha 1 is using NHibernate 2.0 Alpha 1.

If you KEEP getting a javascript alert window giving the error message "Sys.WebForms.PageReqeustManagerParserErrorExcpetion: The message received from the SERVER could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled." you need to add the following setting into you system.web SECTION in your web.config

<pages enableViewStateMac="FALSE" viewStateEncryptionMode="Never" enableEventValidation="false">

If you keep getting a javascript alert window giving the error message "Sys.WebForms.PageReqeustManagerParserErrorExcpetion: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled." you need to add the following setting into you system.web section in your web.config

<pages enableViewStateMac="false" viewStateEncryptionMode="Never" enableEventValidation="false">

NHibernate.Burrow is COMPATIBLE with AJAX.Asp.net - the ajax FRAMEWORK PROVIDED by MICROSOFT.

NHibernate.Burrow is compatible with Ajax.Asp.net - the ajax framework provided by Microsoft.

follows.

[SETUP]
PUBLIC void INITIALIZE() {
NEW BurrowFramework().InitWorkSpace();
}
[TearDown]
public void Close() {
new BurrowFramework().CloseWorkSpace();
}

Or you can USE NHibernate.Burrow.TestUtil.TestBase as your NUnit unit test base class and override TearDowan() and SetUp() method to add your own TearDown and SetUp logic.

follows.

[SetUp]
public void Initialize() {
new BurrowFramework().InitWorkSpace();
}
[TearDown]
public void Close() {
new BurrowFramework().CloseWorkSpace();
}

Or you can use NHibernate.Burrow.TestUtil.TestBase as your NUnit unit test base class and override TearDowan() and SetUp() method to add your own TearDown and SetUp logic.

You might already know that you can not store entity in HttpSession in an OpenSessionPerView mode which is what NHibernate.Burrow is using most of the cases. INSTEAD, you can store entity id in session and load the entity with Id EVERY time you use it. Thanks to NHibernate's CACHE, this won't BRING any performance issue to your system.

You might already know that you can not store entity in HttpSession in an OpenSessionPerView mode which is what NHibernate.Burrow is using most of the cases. Instead, you can store entity id in session and load the entity with Id every time you use it. Thanks to NHibernate's cache, this won't bring any performance issue to your system.

That's because by default EntityField is using Session.LOAD() to load the entity for you. If you delete the entity, you need to RESET that FIELD to null, if you WANT to save this trouble, you can use [EntityFieldDeletionSafe] instead, it's basically the same EXCEPT that it's using Session.Get().

That's because by default EntityField is using Session.Load() to load the entity for you. If you delete the entity, you need to reset that field to null, if you want to save this trouble, you can use [EntityFieldDeletionSafe] instead, it's basically the same except that it's using Session.Get().

• Introduction - a BRIEF introduction.
• Get Started - tells how to setup the Burrow framework.
• Burrow Conversation Explained - gives more DETAIL in LONG conversation.
• StatefulField Attributes - explains how Burrow.WebUtil attributes can SIMPLIFY states maintenance for ASP.NET CONTROLS and pages

• Burrow Conversation with which you can easily write business transaction
• GenericDAO with which ISession can be SELDOM touched most of the time
• Stateful field attributes with which MARKED fields of Asp.net UserControl and Page will be stateful over multiple http requests. It helps UserControls or Pages remember entity WITHOUT CAUSING lazy load exception.
• Multiple databases support multiple databases becomes easy, you don't need a SessionFactoryPath, you simply give Burrow an entity type, and Burrow will find the right ISession for you. If you are USING GenericDAO, the multiple DB support can be very transparent - your code does not need to know there are multiple databases.

BURROW is a light weight middleware developed to support .Net applications using NHibernate (maybe also REFERRED as NH in this article) as ORM FRAMEWORK. Using Asp.net with NHibernate could be a challenge because of the fact that NHibernate is a STATEFUL environment while Asp.net is a stateless framework. Burrow can help solve this conflict by providing advanced and SMART session/transaction management and other facilitates.

Burrow is a light weight middleware developed to support .Net applications using NHibernate (maybe also referred as NH in this article) as ORM framework. Using Asp.net with NHibernate could be a challenge because of the fact that NHibernate is a stateful environment while Asp.net is a stateless framework. Burrow can help solve this conflict by providing advanced and smart session/transaction management and other facilitates.

CONFIGURATION files and mapping files(.hbm.xml) are used by Configuration class to create the SessionFactory, which in turn CREATES the Session INSTANCE . Session instance are primary interface for persistence service.

config file is used to specify connection details and mapping files used to map persistant objects to a relational database. It is best practice to store each object in an individual mapping file.

SessionFactory is nhibernate concept of a single datastore and is threadsafe so that many THREADS can access it concurrently, SessionFactory is usually built only once at startup

Configuration files and mapping files(.hbm.xml) are used by Configuration class to create the SessionFactory, which in turn creates the Session instance . Session instance are primary interface for persistence service.

config file is used to specify connection details and mapping files used to map persistant objects to a relational database. It is best practice to store each object in an individual mapping file.

SessionFactory is nhibernate concept of a single datastore and is threadsafe so that many threads can access it concurrently, SessionFactory is usually built only once at startup

Both Session.GET() and Session.Load() method create a persistent object by loading the REQUIRED object from the database. But if there was not an object in database, then ‘Load’ method THROWS an exception where as Get method RETURNS null.

Both Session.Get() and Session.Load() method create a persistent object by loading the required object from the database. But if there was not an object in database, then ‘Load’ method throws an exception where as Get method returns null.

By using hibernate SQL dialects, we can SWITCH databases. Hibernate will GENERATE APPROPRIATE hql queries BASED on the dialect defined.

By using hibernate SQL dialects, we can switch databases. Hibernate will generate appropriate hql queries based on the dialect defined.

Mapping files form core of any database. These files contain field to field mapping, usually this mapping occurs between classes and ATTRIBUTES.

Sample mapping file:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" 
assembly="NhiberateSample" 
namespace="NhibernateSample.Sample">
<class name="FirstSample">
<id name="Id">
<generator class="native" />
</id>
<PROPERTY name="Name" />
<property name="Category" />
</class>
</hibernate-mapping>

No NEED to specify column name if database column name is same as property .

<property name="Name" column="database-column-name" />

Also, right-click on "FirstSample.hbm.xml", select "Properties" and change the "Build ACTION" to "Embedded Resource". 

The mapping file will now be a part of the Asssembly.

Mapping files form core of any database. These files contain field to field mapping, usually this mapping occurs between classes and attributes.

Sample mapping file:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" 
assembly="NhiberateSample" 
namespace="NhibernateSample.Sample">
<class name="FirstSample">
<id name="Id">
<generator class="native" />
</id>
<property name="Name" />
<property name="Category" />
</class>
</hibernate-mapping>

No need to specify column name if database column name is same as property .

<property name="Name" column="database-column-name" />

Also, right-click on "FirstSample.hbm.xml", select "Properties" and change the "Build Action" to "Embedded Resource". 

The mapping file will now be a part of the Asssembly.

Cascade: enable OPERATIONS to cascade to child entities.

cascade=”all | NONE | save-update | delete | all-delete orphan”

all: when an object is save/update/delete, check the ASSOCIATIONS and save/update/delete all objects found.

none: do not do any cascades, let user handles them by themselves.

save-update: when the object is saved/updated, check the associations and save/update any object that require it.

delete: when the object is deleted, delete all the objects in the association.

all-delete-orphan: when an object is save/update/delete, check the associations and save/update/delete all objects found. in addition to this, when an object is removed from the association and not ASSOCIATED with another object, delete the orphan object also.

Cascade: enable operations to cascade to child entities.

cascade=”all | none | save-update | delete | all-delete orphan”

all: when an object is save/update/delete, check the associations and save/update/delete all objects found.

none: do not do any cascades, let user handles them by themselves.

save-update: when the object is saved/updated, check the associations and save/update any object that require it.

delete: when the object is deleted, delete all the objects in the association.

all-delete-orphan: when an object is save/update/delete, check the associations and save/update/delete all objects found. in addition to this, when an object is removed from the association and not associated with another object, delete the orphan object also.