How to

Changing Values in NHibernate Events

David Gardiner — Fri, 06 Jul 2012 12:34:37 GMT

Current revision posted to How to by David Gardiner on 06/07/2012 09:34:37 a.m.

Changing Values in NHibernate Events

Filed under: events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. Although It may work in some cases and is sometimes referred to as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto"

There is also a bug report about that.

Why OnPreUpdate Triggers May Fail

There is a reason for that. NHibernate does the folowingfollowing:

When flushing, the FlushEntityEventListener is called for each entity in the session.
It determines the dirty properties.
Based on the dirty properties, it determines if the entity needs updating
It calls PreUpdate triggers
Based on the dirty properties it updates the corresponding tables.

The last point is the critical one. If your PreUpdate trigger changes properties that are not found dirty before and which are not in the same table as the dirty properties, it won't be updated in the database. The same happens when dynamic-update is used.

Example:

<class name="Foo">
  <id ...>
  <property name="Name"/>
  <join table="AnotherTable>
    <key name="id"/>
    <property name="Value"/>
  </join>
</class>

Now, when you change Name in the session (it gets dirty) and Value in the trigger, the table AnotherTable won't be updated.

How To Implement It The Correct Way

The correct way is to use the FlushEntityEventListener to implement property changes.The important difference is that you can provide a list of changed properties in this event listener, and therefore tell NHibernate what to store.

There is an example by Buthrakaur.

History

There is a solution to reproduce the code by Scott Findlater here. The tests folder in each project highlights successes/ issues (by failing tests) in each project.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

References to the problem

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post
Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI
And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

There is also this NHibernate bug report - changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes with the resolution of "not an issue" because "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." (see in context)

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

There are some discussions and blog posts related to this problem:

Changing Values in NHibernate Events

Stefan Steinegger — Mon, 08 Aug 2011 15:20:19 GMT

Revision 11 posted to How to by Stefan Steinegger on 08/08/2011 12:20:19 p.m.

Changing Values in OnPreUpdate NHibernate Events

Filed under: events, listener

Abstract

There is also a bug report about that.

Why OnPreUpdate Triggers May Fail

There is a reason for that. NHibernate does the folowing:

When flushing, the FlushEntityEventListener is called for each entity in the session.
It determines the dirty properties.
Based on the dirty properties, it determines if the entity needs updating
It calls PreUpdate triggers
Based on the dirty properties it updates the corresponding tables.

Example:

Now, when you change Name in the session (it gets dirty) and Value in the trigger, the table AnotherTable won't be updated.

How To Implement It The Correct Way

The correct way is to use the FlushEntityEventListener to implement property changeschanges.The important difference is that you can provide a list of changed properties in this event listener, and therefore tell NHibernate what to store.

There is an example by Buthrakaur.

History

There is a solution to reproduce the code by Scott Findlater here. The tests folder in each project highlights successes/ issues (by failing tests) in each project.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

References to the problem

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post
Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI
And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

There are some discussions and blog posts related to this problem:

Changing Values in OnPreUpdate Events

Stefan Steinegger — Mon, 08 Aug 2011 15:17:25 GMT

Revision 10 posted to How to by Stefan Steinegger on 08/08/2011 12:17:25 p.m.

NHibernate, Audit trails and OnPreInsert/ Changing Values in OnPreUpdate event listeners vs Save/ Update event listenersEvents

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works Although It may work in some cases and is widely documented sometimes referred to as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code"veto"

There is also a bug report about that.

Why OnPreUpdate Triggers May Fail

There is a reason for that. NHibernate does the folowing:

When flushing, the FlushEntityEventListener is called for each entity in the session.

It determines the dirty properties.

Based on the dirty properties, it determines if the entity needs updating

It calls PreUpdate triggers

Based on the dirty properties it updates the corresponding tables.

The full solution can last point is the critical one. If your PreUpdate trigger changes properties that are not found dirty before and which are not in the same table as the dirty properties, it won't be downloaded updated in the database. The same happens when dynamic-update is used.

Example:

<class name="Foo">
<id ...>
<property name="Name"/>
<join table="AnotherTable>
<key name="id"/>
<property name="Value"/>
</join>
</class>

Now, when you change Name in the session (it gets dirty) and Value in the trigger, the table AnotherTable won't be updated.

How To Implement It The Correct Way

The correct way is to use the FlushEntityEventListener to implement property changes. There is an example by Buthrakaur.

History

There is a solution to reproduce the code by Scott Findlater here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

History

This section is the history of arriving at this post. Please read this with the spirit of sharing and attempting to contribute

References to documentation.the problem

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post

Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI

And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

And there
There is no doubt all of these solutions work using the concept of changing the state of the entity before (pre) database insertion or updating.

I adopted the OnPreInsert and OnPreUpdate approach for an auditing solution within an inheritance architected solution when I found, what I thought, was an NHibernate bug. I subsequently ended up at also this NHibernate bug report - changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes with the unexpected resolution of "not an issue".

The solution proposed was to use the Save/ Update event listeners, which obviously works, but the unexpected reason as to why this report was not a bug was " because "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." (see in context)

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

Conclusion

I note Fabio clearly states the usage for the OnPre* events and herewith is

There are some documentation. However, from the perspective of a developer learning NHibernate, I feel this is contradicted by key NHibernate community people.

I am yet discussions and blog posts related to truly understand why, with the variety of scenarios demonstrated, this is a not considered a bug. Maybe there should be some explicit enforcing of not being able to change entity state in these OnPre* events.

A detailed example from Fabio?

There seem to be alot of cries for help but with no conclusive working examples;problem:

audit listener using IFlushEntityEventListener (continuation of NH-2596)

Bizarre error when using NHibernate, IPreInsertEventListener, Oracle, batching and sequences

Clarification on NH-2596 of PreUpdate vs OnSaveOrUpdate semantics

And Fabio delivers a blog post

http://fabiomaulo.blogspot.com/2011/05/nhibernate-bizarre-audit.html

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Thu, 12 May 2011 08:47:48 GMT
Revision 9 posted to How to by Scott Findlater on 12/05/2011 05:47:48 a.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

History

This section is the history of arriving at this post. Please read this with the spirit of sharing and attempting to contribute to documentation.

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post

Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI

And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

And there is no doubt all of these solutions work using the concept of changing the state of the entity before (pre) database insertion or updating.

I adopted the OnPreInsert and OnPreUpdate approach for an auditing solution within an inheritance architected solution when I found, what I thought, was an NHibernate bug. I subsequently ended up at this NHibernate bug report - changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes with the unexpected resolution of "not an issue".

The solution proposed was to use the Save/ Update event listeners, which obviously works, but the unexpected reason as to why this report was not a bug was because "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." (see in context)

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

Conclusion

I note Fabio clearly states the usage for the OnPre* events and herewith is some documentation. However, from the perspective of a developer learning NHibernate, I feel this is contradicted by key NHibernate community people.

I am yet to truly understand why, with the variety of scenarios demonstrated, this is a not considered a bug. Maybe there should be some explicit enforcing of not being able to change entity state in these OnPre* events.

A detailed example from Fabio?

There seem to be alot of cries for help but with no conclusive working examples;

audit listener using IFlushEntityEventListener (continuation of NH-2596)

Bizarre error when using NHibernate, IPreInsertEventListener, Oracle, batching and sequences

Clarification on NH-2596 of PreUpdate vs OnSaveOrUpdate semantics

And Fabio delivers a blog post

http://fabiomaulo.blogspot.com/2011/05/nhibernate-bizarre-audit.html

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Wed, 11 May 2011 12:29:26 GMT
Revision 8 posted to How to by Scott Findlater on 11/05/2011 09:29:26 a.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

History

This section is the history of arriving at this post. Please read this with the spirit of sharing and attempting to contribute to documentation.

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post

Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI

And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

And there is no doubt all of these solutions work using the concept of changing the state of the entity before (pre) database insertion or updating.

I adopted the OnPreInsert and OnPreUpdate approach for an auditing solution within an inheritance architected solution when I found, what I thought, was an NHibernate bug. I subsequently ended up at this NHibernate bug report - changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes with the unexpected resolution of "not an issue".

The solution proposed was to use the Save/ Update event listeners, which obviously works, but the unexpected reason as to why this report was not a bug was because "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." (see in context)

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

Conclusion

I note Fabio clearly states the usage for the OnPre* events and herewith is some documentation. However, from the perspective of a developer learning NHibernate, I feel this is contradicted by key NHibernate community people.

I am yet to truly understand why, with the variety of scenarios demonstrated, this is a not considered a bug. Maybe there should be some explicit enforcing of not being able to change entity state in these OnPre* events.

A detailed example from Fabio?

There seem to be alot of cries for help but with no conclusive working examples;

audit listener using IFlushEntityEventListener (continuation of NH-2596)

Bizarre error when using NHibernate, IPreInsertEventListener, Oracle, batching and sequences

Clarification on NH-2596 of PreUpdate vs OnSaveOrUpdate semantics

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Wed, 27 Apr 2011 05:32:27 GMT
Revision 7 posted to How to by Scott Findlater on 27/04/2011 02:32:27 a.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

History

This section is the history of arriving at this post. Please read this with the spirit of sharing and attempting to contribute to documentation.

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post

Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI

And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

And there is no doubt all of these solutions work using the concept of changing the state of the entity before (pre) database insertion or updating.

I adopted the OnPreInsert and OnPreUpdate approach for an auditing solution within an inheritance architected solution when I found, what I thought, was an NHibernate bug. I subsequently ended up at this NHibernate bug report - changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes with the unexpected resolution of "not an issue".

The solution proposed was to use the Save/ Update event listeners, which obviously works, but the unexpected reason as to why this report was not a bug was because "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." (see in context)

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

Conclusion

I note Fabio clearly states the usage for the OnPre* events and herewith is some documentation. However, from the perspective of a developer learning NHibernate, I feel this is contradicted by key NHibernate community people.

I am yet to truly understand why, with the variety of scenarios demonstrated, this is a not considered a bug. Maybe there should be some explicit enforcing of not being able to change entity state in these OnPre* events.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Tue, 26 Apr 2011 23:42:34 GMT
Revision 6 posted to How to by Scott Findlater on 26/04/2011 08:42:34 p.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

History

This section is the history of arriving at this post. Please read this with the spirit of sharing and attempting to contribute to documentation.

Audit trails using NHibernate's event model are well documented;

Ayende's NHibernate IPreUpdateEventListener & IPreInsertEventListener blog post

Graham Bunce's Creating an Audit Log using NHibernate Events on this WIKI

And most recently Jason Dentler's NHibernate 3.0 cookbook, chapter 7, Creating and changing stamping entities recipe.

And there is no doubt all of these solutions work using the concept of changing the state of the entity before (pre) database insertion or updating.

I adopted the OnPreInsert and OnPreUpdate approach for an auditing solution within an inheritance architected solution when I found, what I thought, was an NHibernate bug. I subsequently ended up at this NHibernate bug report - changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes with the unexpected resolution of "not an issue".

The solution proposed was to use the Save/ Update event listeners, which obviously works, but the unexpected reason as to why this report was not a bug was because "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." (see in context)

This contradiction of intended usage regarding the changing of entity state was further discussed on this NHUser Group thread, with the same answer.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Tue, 26 Apr 2011 23:40:44 GMT
Revision 5 posted to How to by Scott Findlater on 26/04/2011 08:40:44 p.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

Project - 03Save. Uses the same entity inheritance hierarchy from the 02OnPreEventsFailing project to demonstrate a working version using the Save/ Insert events.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Tue, 26 Apr 2011 23:40:12 GMT
Revision 4 posted to How to by Scott Findlater on 26/04/2011 08:40:12 p.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

Project - 02OnPreEventsFailing. This project shows how an inheritance entity hierarchy using the OnPreInsert and OnPreUpdate events to modify entity state fail to persist the changed entity state. Here, for whatever design decision, the Entity base class which originally provide identification and common auditing has been split into Entity and AuditableEntity. Now the Category class inherits from AuditableEntity.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Tue, 26 Apr 2011 23:39:37 GMT
Revision 3 posted to How to by Scott Findlater on 26/04/2011 08:39:37 p.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

Code

The full solution can be downloaded here. The tests folder in each project highlights successes/ issues (by failing tests) in each project. May I politely ask you to bear in mind the aim of this code is the issue of inheritance and they have been over simplified with auditing in mind to demonstrate inheritance issues within NHibernate ... this is not a commercial design pattern/ solution.

Project - 01OnPreEvents. This project shows a typical, working, approach to audit trails using the OnPreInsert and OnPreUpdate to modify the entity state. An Entity base class which is inherited by a Category class. The base Entity provides identification and common auditing properties.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Tue, 26 Apr 2011 23:37:53 GMT
Revision 2 posted to How to by Scott Findlater on 26/04/2011 08:37:53 p.m.

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Filed under: Audit, log, events, listener

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

NHibernate, Audit trails and OnPreInsert/ OnPreUpdate event listeners vs Save/ Update event listeners

Scott Findlater — Tue, 26 Apr 2011 23:37:53 GMT
Revision 1 posted to How to by Scott Findlater on 26/04/2011 08:37:53 p.m.

Abstract

Audit trails using NHibernate's event model often use the OnPreInsert and OnPreUpdate event listeners to change/ modify the state of the entity. While this does works and is widely documented as a solution, it should be noted the OnPreInsert and OnPreUpdate events are not intended to be used to change the values of the entity and instead they should be used to check values and for that reason they return "veto".

WCF + NHibernate: Entity Serialization

awgneo — Sat, 28 Jan 2012 22:29:15 GMT
Current revision posted to How to by awgneo on 28/01/2012 07:29:15 p.m.

WCF + NHibernate: Entity Serialization

Filed under: lazy loading, Nhibernate, FluentNH

I found many examples online covering how to serialize NHibernate entities for use over a WCF channel, while still using lazy and eager loading. In my application, my database models and my SOA models needed to be exactly the same; therefore, I wanted to avoid the use of DTOs. However, none of the examples I found quite worked for me.

Examples I found included:

IDataContractSurrogate (http://www.timvasil.com/blog14/post/2008/02/WCF-serialization-with-NHibernate.aspx) that allows WCF to attempt serialization by walking over the object graph (has a bug that does not allow proper XML generation: http://connect.microsoft.com/wcf/feedback/details/404241/method-object-getobjecttoserialize-object-obj-type-targettype-of-idatacontractsurrogate-can-not-return-null)

Standard Object Graph Walking (http://trentacular.com/2009/08/how-to-use-nhibernate-lazy-initializing-proxies-with-web-services-or-wcf/) this example did not work for me at all, but it was close to my final solution. Additionally, this example does not support collections.

My custom object graph walker (I hacked this out of some integrated code so it may need some tweaking):

using System; using System.Collections.Generic; using System.Collections; using System.Reflection; using System.Data; using System.Linq; using System.Configuration; using FluentNHibernate.Cfg; using FluentNHibernate.Cfg.Db; using NHibernate; using NHibernate.Cfg; using NHibernate.Tool.hbm2ddl; using FluentNHibernate.Automapping; using Radiant.RQS.Services.Types; using Radiant.RQS.Services.Core.Conventions; using Radiant.RQS.Superbank; using NHibernate.Proxy; using NHibernate.Collection; using NHibernate.Metadata; using NHibernate.Type; namespace Radiant.RQS.Services.Core {     public static class Resolver     {         public static List<T> ResolveList<T>(List<T> entityList, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityListIndex = 0; entityListIndex < entityList.Count; entityListIndex++)                 entityList[entityListIndex] = Resolve<T>(entityList[entityListIndex], resolvedEntities, session); <T>(entityList[entityListIndex], session, resolvedEntities);             // done             return entityList;         }         public static T[] ResolveArray<T>(T[] entityArray, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityArrayIndex = 0; entityArrayIndex < entityArray.Length; entityArrayIndex++)                 entityArray[entityArrayIndex] = Resolve<T>(entityArray[entityArrayIndex], resolvedEntities, session); <T>(entityArray[entityArrayIndex], session, resolvedEntities);             // done             return entityArray;         }         public static T Resolve<T>(T entity, ISession session) where T : class         {             // forward to resolver             return Resolve<T>(entity, new List<Object>(), session); <T>(entity, session, new List<Object>());         }         private static T Resolve<T>(T entity, List<Object> resolvedEntities, ISession session) where T : class <T>(T entity, ISession session, List<Object> resolvedEntities) where T : class

        {             // CHECKS //             // if the entity is null, just skip it             if (entity == null)                 return default(T);             // if we have already resolved it, return that             if (resolvedEntities.Contains(entity))                 return entity;             // RESOLVE ENTITY //             T resolvedEntity = default(T);             // now lets go ahead and make sure everything is unproxied             try { resolvedEntity = (T)session.GetSessionImplementation().PersistenceContext.Unproxy(entity); }             catch (Exception ex) { return default(T); }             // add entity to the list of resolved entities             resolvedEntities.Add(resolvedEntity);             // GET TYPE INFO //             IClassMetadata entityMetadata = null;             // get the entity type             Type entityType = entity.GetType();             // get the entity meta data from the type             try { entityMetadata = session.SessionFactory.GetClassMetadata(entityType); }             catch (Exception ex) { return default(T); }             // PERFORM PROPERTY DIVE //             String propertyName;             Object propertyValue;             Type propertyListType;             IType entityPropertyType = null;             Type propertyListInternalType;             // get properties for this object             PropertyInfo[] propertyInfos = entityType.GetProperties();             // loop over source properties & compare             foreach (PropertyInfo propertyInfo in propertyInfos)             {                 // get property name                 propertyName = propertyInfo.Name;                 // get property type                 try { entityPropertyType = entityMetadata.GetPropertyType(propertyName); }                 catch (Exception ex) { continue; }                 // get property value                 propertyValue = propertyInfo.GetValue(entity, null);                 // these are not the good kind of bags :P                 if (entityPropertyType.IsCollectionType)                 {                     // first get the property list's internal type                     propertyListInternalType = propertyInfo.PropertyType.GetGenericArguments()[0];                     // create new array type based on the internal type                     propertyListType = typeof(List<>).MakeGenericType(propertyListInternalType);                     // create a new property list of the internal type                     IList propertyList = (IList)Activator.CreateInstance(propertyListType);                     // set the property list in the resolved object                     propertyInfo.SetValue(resolvedEntity, propertyList, null);                     // get the enumerator for this property value                     IEnumerator enumerator = ((IEnumerable)propertyValue).GetEnumerator();                     // loop over items to also perform resolution                     while (enumerator.MoveNext())                         propertyList.Add(Resolve(enumerator.Current, session, resolvedEntities));                 }                 // destroy hibernate proxies                 else if (entityPropertyType.IsEntityType)                 {                     // set the property of the resolved entity to the child beneath us                     propertyInfo.SetValue(resolvedEntity, Resolve(propertyValue, session, resolvedEntities), null);                 }             }             // return the resolved entity :)             return resolvedEntity;         }     } }

This works FLAWLESSLY for me. When I lazy load or eager load sub-entities before calling Resolve() it perfectly serializes only what I want and does not attempt to lazy load the entire DB.

Example:

// get the computer query

var computerQuery =

from c in context.Session.Query<Types.Computer>()

where c.ID == computerID

select c;

// return computer

return Resolver.Resolve<Types.Computer>(computerQuery.SingleOrDefault(), session);

Let me know if this doesn't work for you :).

Thanks,
Alex G. (awgneo@xbetanet.com)

WCF + NHibernate: Entity Serialization

awgneo — Sat, 28 Jan 2012 22:23:22 GMT
Revision 4 posted to How to by awgneo on 28/01/2012 07:23:22 p.m.

WCF + NHibernate: Entity Serialization

Filed under: lazy loading, Nhibernate, FluentNH

I found many examples online covering how to serialize NHibernate entities for use over a WCF channel, while still using lazy and eager loading. In my application, my database models and my SOA models needed to be exactly the same; therefore, I wanted to avoid the use of DTOs. However, none of the examples I found quite worked for me.

Examples I found included:

IDataContractSurrogate (http://www.timvasil.com/blog14/post/2008/02/WCF-serialization-with-NHibernate.aspx) that allows WCF to attempt serialization by walking over the object graph (has a bug that does not allow proper XML generation: http://connect.microsoft.com/wcf/feedback/details/404241/method-object-getobjecttoserialize-object-obj-type-targettype-of-idatacontractsurrogate-can-not-return-null)

Standard Object Graph Walking (http://trentacular.com/2009/08/how-to-use-nhibernate-lazy-initializing-proxies-with-web-services-or-wcf/) this example did not work for me at all, but it was close to my final solution. Additionally, this example does not support collections.

My custom object graph walker (I hacked this out of some integrated code so it may need some tweaking):

using System; using System.Collections.Generic; using System.Collections; using System.Reflection; using System.Data; using System.Linq; using System.Configuration; using FluentNHibernate.Cfg; using FluentNHibernate.Cfg.Db; using NHibernate; using NHibernate.Cfg; using NHibernate.Tool.hbm2ddl; using FluentNHibernate.Automapping; using Radiant.RQS.Services.Types; using Radiant.RQS.Services.Core.Conventions; using Radiant.RQS.Superbank; using NHibernate.Proxy; using NHibernate.Collection; using NHibernate.Metadata; using NHibernate.Type; namespace Radiant.RQS.Services.Core {     public static class Resolver     {         public static List<T> ResolveList<T>(List<T> entityList, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityListIndex = 0; entityListIndex < entityList.Count; entityListIndex++)                 entityList[entityListIndex] = Resolve<T>(entityList[entityListIndex], resolvedEntities, session);             // done             return entityList;         }         public static T[] ResolveArray<T>(T[] entityArray, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityArrayIndex = 0; entityArrayIndex < entityArray.Length; entityArrayIndex++)                 entityArray[entityArrayIndex] = Resolve<T>(entityArray[entityArrayIndex], resolvedEntities, session);             // done             return entityArray;         }         public static T Resolve<T>(T entity, ISession session) where T : class         {             // forward to resolver             return Resolve<T>(entity, new List<Object>(), session);         }         private static T Resolve<T>(T entity, List<Object> resolvedEntities, ISession session) where T : class         {             // CHECKS //             // if the entity is null, just skip it             if (entity == null)                 return default(T);             // if we have already resolved it, return that             if (resolvedEntities.Contains(entity))                 return entity;             // RESOLVE ENTITY //             T resolvedEntity = default(T);             // now lets go ahead and make sure everything is unproxied             try { resolvedEntity = (T)session.GetSessionImplementation().PersistenceContext.Unproxy(entity); }             catch (Exception ex) { return default(T); }             // add entity to the list of resolved entities             resolvedEntities.Add(resolvedEntity);             // GET TYPE INFO //             IClassMetadata entityMetadata = null;             // get the entity type             Type entityType = entity.GetType();             // get the entity meta data from the type             try { entityMetadata = session.SessionFactory.GetClassMetadata(entityType); }             catch (Exception ex) { return default(T); }             // PERFORM PROPERTY DIVE //             String propertyName;             Object propertyValue;             Type propertyListType;             IType entityPropertyType = null;             Type propertyListInternalType;             // get properties for this object             PropertyInfo[] propertyInfos = entityType.GetProperties();             // loop over source properties & compare             foreach (PropertyInfo propertyInfo in propertyInfos)             {                 // get property name                 propertyName = propertyInfo.Name;                 // get property type                 try { entityPropertyType = entityMetadata.GetPropertyType(propertyName); }                 catch (Exception ex) { continue; }                 // get property value                 propertyValue = propertyInfo.GetValue(entity, null);                 // these are not the good kind of bags :P                 if (entityPropertyType.IsCollectionType)                 {                     // first get the property list's internal type                     propertyListInternalType = propertyInfo.PropertyType.GetGenericArguments()[0];                     // create new array type based on the internal type                     propertyListType = typeof(List<>).MakeGenericType(propertyListInternalType);                     // create a new property list of the internal type                     IList propertyList = (IList)Activator.CreateInstance(propertyListType);                     // set the property list in the resolved object                     propertyInfo.SetValue(resolvedEntity, propertyList, null);                     // get the enumerator for this property value                     IEnumerator enumerator = ((IEnumerable)propertyValue).GetEnumerator();                     // loop over items to also perform resolution                     while (enumerator.MoveNext())                         propertyList.Add(Resolve(enumerator.Current, resolvedEntities));                 }                 // destroy hibernate proxies                 else if (entityPropertyType.IsEntityType)                 {                     // set the property of the resolved entity to the child beneath us                     propertyInfo.SetValue(resolvedEntity, Resolve(propertyValue, resolvedEntities), null);                 }             }             // return the resolved entity :)             return resolvedEntity;         }     } }

This works FLAWLESSLY for me. When I lazy load or eager load sub-entities before calling Resolve() it perfectly serializes only what I want and does not attempt to lazy load the entire DB.

Let me know if this doesn't work for you :).

Thanks,

Alex G.

WCF + NHibernate: Entity Serialization

awgneo — Sat, 28 Jan 2012 22:22:37 GMT
Revision 3 posted to How to by awgneo on 28/01/2012 07:22:37 p.m.

WCF + NHibernate: Entity Serialization

Filed under: lazy loading, Nhibernate, FluentNH

I found many examples online on covering how to serialize NHibernate entities for use over a WCF channel, while still using lazy and eager loading. In my application, my database models and my SOA models needed to be exactly the same; therefore, I wanted to avoid the use of DTOs. However, none of the examples I found quite worked for me.

Examples I found included:

IDataContractSurrogate (http://www.timvasil.com/blog14/post/2008/02/WCF-serialization-with-NHibernate.aspx) that allows WCF to attempt serialization by walking over the object graph (has a bug that does not allow proper XML generation: http://connect.microsoft.com/wcf/feedback/details/404241/method-object-getobjecttoserialize-object-obj-type-targettype-of-idatacontractsurrogate-can-not-return-null)

Standard Object Graph Walking (http://trentacular.com/2009/08/how-to-use-nhibernate-lazy-initializing-proxies-with-web-services-or-wcf/) this example did not work for me at all, but it was close to my final solution. Additionally, this example does not support collections

My custom object graph walker (I hacked this out of some integrated code so it may need some tweaking):

using System; using System.Collections.Generic; using System.Collections; using System.Reflection; using System.Data; using System.Linq; using System.Configuration; using FluentNHibernate.Cfg; using FluentNHibernate.Cfg.Db; using NHibernate; using NHibernate.Cfg; using NHibernate.Tool.hbm2ddl; using FluentNHibernate.Automapping; using Radiant.RQS.Services.Types; using Radiant.RQS.Services.Core.Conventions; using Radiant.RQS.Superbank; using NHibernate.Proxy; using NHibernate.Collection; using NHibernate.Metadata; using NHibernate.Type; namespace Radiant.RQS.Services.Core {     public static class Resolver     {         public static List<T> ResolveList<T>(List<T> entityList, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityListIndex = 0; entityListIndex < entityList.Count; entityListIndex++)                 entityList[entityListIndex] = Resolve<T>(entityList[entityListIndex], resolvedEntities, session);             // done             return entityList;         }         public static T[] ResolveArray<T>(T[] entityArray, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityArrayIndex = 0; entityArrayIndex < entityArray.Length; entityArrayIndex++)                 entityArray[entityArrayIndex] = Resolve<T>(entityArray[entityArrayIndex], resolvedEntities, session);             // done             return entityArray;         }         public static T Resolve<T>(T entity, ISession session) where T : class         {             // forward to resolver             return Resolve<T>(entity, new List<Object>(), session);         }         private static T Resolve<T>(T entity, List<Object> resolvedEntities, ISession session) where T : class         {             // CHECKS //             // if the entity is null, just skip it             if (entity == null)                 return default(T);             // if we have already resolved it, return that             if (resolvedEntities.Contains(entity))                 return entity;             // RESOLVE ENTITY //             T resolvedEntity = default(T);             // now lets go ahead and make sure everything is unproxied             try { resolvedEntity = (T)session.GetSessionImplementation().PersistenceContext.Unproxy(entity); }             catch (Exception ex) { return default(T); }             // add entity to the list of resolved entities             resolvedEntities.Add(resolvedEntity);             // GET TYPE INFO //             IClassMetadata entityMetadata = null;             // get the entity type             Type entityType = entity.GetType();             // get the entity meta data from the type             try { entityMetadata = session.SessionFactory.GetClassMetadata(entityType); }             catch (Exception ex) { return default(T); }             // PERFORM PROPERTY DIVE //             String propertyName;             Object propertyValue;             Type propertyListType;             IType entityPropertyType = null;             Type propertyListInternalType;             // get properties for this object             PropertyInfo[] propertyInfos = entityType.GetProperties();             // loop over source properties & compare             foreach (PropertyInfo propertyInfo in propertyInfos)             {                 // get property name                 propertyName = propertyInfo.Name;                 // get property type                 try { entityPropertyType = entityMetadata.GetPropertyType(propertyName); }                 catch (Exception ex) { continue; }                 // get property value                 propertyValue = propertyInfo.GetValue(entity, null);                 // these are not the good kind of bags :P                 if (entityPropertyType.IsCollectionType)                 {                     // first get the property list's internal type                     propertyListInternalType = propertyInfo.PropertyType.GetGenericArguments()[0];                     // create new array type based on the internal type                     propertyListType = typeof(List<>).MakeGenericType(propertyListInternalType);                     // create a new property list of the internal type                     IList propertyList = (IList)Activator.CreateInstance(propertyListType);                     // set the property list in the resolved object                     propertyInfo.SetValue(resolvedEntity, propertyList, null);                     // get the enumerator for this property value                     IEnumerator enumerator = ((IEnumerable)propertyValue).GetEnumerator();                     // loop over items to also perform resolution                     while (enumerator.MoveNext())                         propertyList.Add(Resolve(enumerator.Current, resolvedEntities));                 }                 // destroy hibernate proxies                 else if (entityPropertyType.IsEntityType)                 {                     // set the property of the resolved entity to the child beneath us                     propertyInfo.SetValue(resolvedEntity, Resolve(propertyValue, resolvedEntities), null);                 }             }             // return the resolved entity :)             return resolvedEntity;         }     } }

This works FLAWLESSLY for me. When I lazy load or eager load sub-entities before calling Resolve() it perfectly serializes only what I want and does not attempt to lazy load the entire DB.

Let me know if this doesn't work for you :).

Thanks,

Alex G.

WCF + NHibernate: Entity Serialization

awgneo — Sat, 28 Jan 2012 22:22:19 GMT
Revision 2 posted to How to by awgneo on 28/01/2012 07:22:19 p.m.

WCF + NHibernate: Entity Serialization

Filed under: lazy loading, Nhibernate, FluentNH

I found many example examples online on how to serialize NHibernate entities for use over a WCF channel, while still using lazy and eager loading. In my application, my database models and my SOA models needed to be exactly the same; therefore, I wanted to avoid the use of DTOs. However, none of the examples I found quite worked for me.

Examples I found included:

IDataContractSurrogate (http://www.timvasil.com/blog14/post/2008/02/WCF-serialization-with-NHibernate.aspx) that allows WCF to attempt serialization by walking over the object graph (has a bug that does not allow proper XML generation: http://connect.microsoft.com/wcf/feedback/details/404241/method-object-getobjecttoserialize-object-obj-type-targettype-of-idatacontractsurrogate-can-not-return-null)

Standard Object Graph Walking (http://trentacular.com/2009/08/how-to-use-nhibernate-lazy-initializing-proxies-with-web-services-or-wcf/) this example did not work for me at all, but it was close to my final solution. Additionally, this example does not support collections

My custom object graph walker (I hacked this out of some integrated code so it may need some tweaking):

using System; using System.Collections.Generic; using System.Collections; using System.Reflection; using System.Data; using System.Linq; using System.Configuration; using FluentNHibernate.Cfg; using FluentNHibernate.Cfg.Db; using NHibernate; using NHibernate.Cfg; using NHibernate.Tool.hbm2ddl; using FluentNHibernate.Automapping; using Radiant.RQS.Services.Types; using Radiant.RQS.Services.Core.Conventions; using Radiant.RQS.Superbank; using NHibernate.Proxy; using NHibernate.Collection; using NHibernate.Metadata; using NHibernate.Type; namespace Radiant.RQS.Services.Core {     public static class Resolver     {         public static List<T> ResolveList<T>(List<T> entityList, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityListIndex = 0; entityListIndex < entityList.Count; entityListIndex++)                 entityList[entityListIndex] = Resolve<T>(entityList[entityListIndex], resolvedEntities, session);             // done             return entityList;         }         public static T[] ResolveArray<T>(T[] entityArray, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityArrayIndex = 0; entityArrayIndex < entityArray.Length; entityArrayIndex++)                 entityArray[entityArrayIndex] = Resolve<T>(entityArray[entityArrayIndex], resolvedEntities, session);             // done             return entityArray;         }         public static T Resolve<T>(T entity, ISession session) where T : class         {             // forward to resolver             return Resolve<T>(entity, new List<Object>(), session);         }         private static T Resolve<T>(T entity, List<Object> resolvedEntities, ISession session) where T : class         {             // CHECKS //             // if the entity is null, just skip it             if (entity == null)                 return default(T);             // if we have already resolved it, return that             if (resolvedEntities.Contains(entity))                 return entity;             // RESOLVE ENTITY //             T resolvedEntity = default(T);             // now lets go ahead and make sure everything is unproxied             try { resolvedEntity = (T)session.GetSessionImplementation().PersistenceContext.Unproxy(entity); }             catch (Exception ex) { return default(T); }             // add entity to the list of resolved entities             resolvedEntities.Add(resolvedEntity);             // GET TYPE INFO //             IClassMetadata entityMetadata = null;             // get the entity type             Type entityType = entity.GetType();             // get the entity meta data from the type             try { entityMetadata = session.SessionFactory.GetClassMetadata(entityType); }             catch (Exception ex) { return default(T); }             // PERFORM PROPERTY DIVE //             String propertyName;             Object propertyValue;             Type propertyListType;             IType entityPropertyType = null;             Type propertyListInternalType;             // get properties for this object             PropertyInfo[] propertyInfos = entityType.GetProperties();             // loop over source properties & compare             foreach (PropertyInfo propertyInfo in propertyInfos)             {                 // get property name                 propertyName = propertyInfo.Name;                 // get property type                 try { entityPropertyType = entityMetadata.GetPropertyType(propertyName); }                 catch (Exception ex) { continue; }                 // get property value                 propertyValue = propertyInfo.GetValue(entity, null);                 // these are not the good kind of bags :P                 if (entityPropertyType.IsCollectionType)                 {                     // first get the property list's internal type                     propertyListInternalType = propertyInfo.PropertyType.GetGenericArguments()[0];                     // create new array type based on the internal type                     propertyListType = typeof(List<>).MakeGenericType(propertyListInternalType);                     // create a new property list of the internal type                     IList propertyList = (IList)Activator.CreateInstance(propertyListType);                     // set the property list in the resolved object                     propertyInfo.SetValue(resolvedEntity, propertyList, null);                     // get the enumerator for this property value                     IEnumerator enumerator = ((IEnumerable)propertyValue).GetEnumerator();                     // loop over items to also perform resolution                     while (enumerator.MoveNext())                         propertyList.Add(Resolve(enumerator.Current, resolvedEntities));                 }                 // destroy hibernate proxies                 else if (entityPropertyType.IsEntityType)                 {                     // set the property of the resolved entity to the child beneath us                     propertyInfo.SetValue(resolvedEntity, Resolve(propertyValue, resolvedEntities), null);                 }             }             // return the resolved entity :)             return resolvedEntity;         }     } }

This works FLAWLESSLY for me. When I lazy load or eager load sub-entities before calling Resolve() it perfectly serializes only what I want and does not attempt to lazy load the entire DB.

Let me know if this doesn't work for you :).

Thanks,

Alex G.

WCF + NHibernate: Entity Serialization

awgneo — Sat, 28 Jan 2012 22:21:48 GMT
Revision 1 posted to How to by awgneo on 28/01/2012 07:21:48 p.m.

I found many example online on how to serialize NHibernate entities for use over a WCF channel, while still using lazy and eager loading. In my application, my database models and my SOA models needed to be exactly the same; therefore, I wanted to avoid the use of DTOs. However, none of the examples I found quite worked for me.

Examples I found included:

IDataContractSurrogate (http://www.timvasil.com/blog14/post/2008/02/WCF-serialization-with-NHibernate.aspx) that allows WCF to attempt serialization by walking over the object graph (has a bug that does not allow proper XML generation: http://connect.microsoft.com/wcf/feedback/details/404241/method-object-getobjecttoserialize-object-obj-type-targettype-of-idatacontractsurrogate-can-not-return-null)

Standard Object Graph Walking (http://trentacular.com/2009/08/how-to-use-nhibernate-lazy-initializing-proxies-with-web-services-or-wcf/) this example did not work for me at all, but it was close to my final solution. Additionally, this example does not support collections

My custom object graph walker (I hacked this out of some integrated code so it may need some tweaking):

using System; using System.Collections.Generic; using System.Collections; using System.Reflection; using System.Data; using System.Linq; using System.Configuration; using FluentNHibernate.Cfg; using FluentNHibernate.Cfg.Db; using NHibernate; using NHibernate.Cfg; using NHibernate.Tool.hbm2ddl; using FluentNHibernate.Automapping; using Radiant.RQS.Services.Types; using Radiant.RQS.Services.Core.Conventions; using Radiant.RQS.Superbank; using NHibernate.Proxy; using NHibernate.Collection; using NHibernate.Metadata; using NHibernate.Type; namespace Radiant.RQS.Services.Core {     public static class Resolver     {         public static List<T> ResolveList<T>(List<T> entityList, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityListIndex = 0; entityListIndex < entityList.Count; entityListIndex++)                 entityList[entityListIndex] = Resolve<T>(entityList[entityListIndex], resolvedEntities, session);             // done             return entityList;         }         public static T[] ResolveArray<T>(T[] entityArray, ISession session) where T : class         {             // create a resolved entities list for peace and sharing             List<Object> resolvedEntities = new List<Object>();             // loop over elements             for (int entityArrayIndex = 0; entityArrayIndex < entityArray.Length; entityArrayIndex++)                 entityArray[entityArrayIndex] = Resolve<T>(entityArray[entityArrayIndex], resolvedEntities, session);             // done             return entityArray;         }         public static T Resolve<T>(T entity, ISession session) where T : class         {             // forward to resolver             return Resolve<T>(entity, new List<Object>(), session);         }         private static T Resolve<T>(T entity, List<Object> resolvedEntities, ISession session) where T : class         {             // CHECKS //             // if the entity is null, just skip it             if (entity == null)                 return default(T);             // if we have already resolved it, return that             if (resolvedEntities.Contains(entity))                 return entity;             // RESOLVE ENTITY //             T resolvedEntity = default(T);             // now lets go ahead and make sure everything is unproxied             try { resolvedEntity = (T)session.GetSessionImplementation().PersistenceContext.Unproxy(entity); }             catch (Exception ex) { return default(T); }             // add entity to the list of resolved entities             resolvedEntities.Add(resolvedEntity);             // GET TYPE INFO //             IClassMetadata entityMetadata = null;             // get the entity type             Type entityType = entity.GetType();             // get the entity meta data from the type             try { entityMetadata = session.SessionFactory.GetClassMetadata(entityType); }             catch (Exception ex) { return default(T); }             // PERFORM PROPERTY DIVE //             String propertyName;             Object propertyValue;             Type propertyListType;             IType entityPropertyType = null;             Type propertyListInternalType;             // get properties for this object             PropertyInfo[] propertyInfos = entityType.GetProperties();             // loop over source properties & compare             foreach (PropertyInfo propertyInfo in propertyInfos)             {                 // get property name                 propertyName = propertyInfo.Name;                 // get property type                 try { entityPropertyType = entityMetadata.GetPropertyType(propertyName); }                 catch (Exception ex) { continue; }                 // get property value                 propertyValue = propertyInfo.GetValue(entity, null);                 // these are not the good kind of bags :P                 if (entityPropertyType.IsCollectionType)                 {                     // first get the property list's internal type                     propertyListInternalType = propertyInfo.PropertyType.GetGenericArguments()[0];                     // create new array type based on the internal type                     propertyListType = typeof(List<>).MakeGenericType(propertyListInternalType);                     // create a new property list of the internal type                     IList propertyList = (IList)Activator.CreateInstance(propertyListType);                     // set the property list in the resolved object                     propertyInfo.SetValue(resolvedEntity, propertyList, null);                     // get the enumerator for this property value                     IEnumerator enumerator = ((IEnumerable)propertyValue).GetEnumerator();                     // loop over items to also perform resolution                     while (enumerator.MoveNext())                         propertyList.Add(Resolve(enumerator.Current, resolvedEntities));                 }                 // destroy hibernate proxies                 else if (entityPropertyType.IsEntityType)                 {                     // set the property of the resolved entity to the child beneath us                     propertyInfo.SetValue(resolvedEntity, Resolve(propertyValue, resolvedEntities), null);                 }             }             // return the resolved entity :)             return resolvedEntity;         }     } }

This works FLAWLESSLY for me. When I lazy load or eager load sub-entities before calling Resolve() it perfectly serializes only what I want and does not attempt to lazy load the entire DB.

Let me know if this doesn't work for you :).

Thanks,

Alex G.

Mapping tables

oceantrain — Wed, 23 Nov 2011 15:01:29 GMT
Current revision posted to How to by oceantrain on 23/11/2011 12:01:29 p.m.

I'm new to NHibernate, So I'm not sure if I this is even the place to ask questions. But here goes.

This is my problem:

I am building a website using Orchard CMS. All the Orchard tables are mapped by NHibernate. I also have tables in the same database that are NOT mapped by NHibernate. These tables were provided by the client. I need to query these tables and display data on the front end using Orchard. I must keep the table schemas in tact. I have a tutorial on how to map tables using NHibernate, however everything I see in the tutorials, requires the tables to have an ID column as the Primary key. None of the tables provided to me by the client have ID as the first/Primary key column. Is it possible to map to these tables without using the ID method? Or a variation of the ID method?

Id(x => x.Id);

Instead can I map to the table using:

MyColumnName/Primarykey(x => x.Id);

or

Id(x => x.MyColumnname/PrimaryKey);

Again, at this point I cannot migrate the data into new tables mapped by NHibernate and also the table schema must remain in tact. As the Client is updating these tables on a nightly bases.

Any help is appreciated.

Thanks

Oceantrain

:

Creating a custom id generator for nHibernate

Steve Bohlen — Sun, 20 Nov 2011 23:29:17 GMT
Current revision posted to How to by Steve Bohlen on 20/11/2011 08:29:17 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the DDL to generate the table to store the next id value for my custom id is only created once and does not check the column name value for each class. For my id generator there is a separate column used for each table in the database, so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding, but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Source :

packshot 360

Creating a custom id generator for nHibernate

marcusix — Sun, 20 Nov 2011 22:56:44 GMT
Revision 10 posted to How to by marcusix on 20/11/2011 07:56:44 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am.Buy Essay Online I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.Write My Essay For Me

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Cur rently
Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it. Hill University Accreditation AND About Woodfield University

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.UK Essay Help

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.Rochville University AND Adisonhighschool AND Corllins University Review

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.Essay Writing Service

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator.Logo Contests I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the DDL to generate the table to store the next id value for my custom id is only created once and does not check the column name value for each class. For my id generator there is a separate column used for each table in the database, so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding, but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Source :

packshot 360

Creating a custom id generator for nHibernate

smithwilsonrogard — Wed, 12 Oct 2011 10:43:32 GMT
Revision 9 posted to How to by smithwilsonrogard on 12/10/2011 07:43:32 a.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am.Buy Essay Online I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.Write My Essay For Me

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it. Hill University Accreditation AND About Woodfield University

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.UK Essay Help

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate. Rochville University AND Adisonhighschool AND Corllins University Review

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.Essay Writing Service

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator.Logo Contests I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the DDL to generate the table to store the next id value for my custom id is only created once and does not check the column name value for each class. For my id generator there is a separate column used for each table in the database, so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding, but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

suedallin — Wed, 06 Apr 2011 16:58:15 GMT
Revision 8 posted to How to by suedallin on 06/04/2011 01:58:15 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it. Hill University Accreditation AND About Woodfield University

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate. Rochville University AND Adisonhighschool AND Corllins University Review

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the DDL to generate the table to store the next id value for my custom id is only created once and does not check the column name value for each class. For my id generator there is a separate column used for each table in the database, so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding, but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

markweee — Wed, 30 Mar 2011 11:46:10 GMT
Revision 7 posted to How to by markweee on 30/03/2011 08:46:10 a.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it. Hill University Accreditation AND About Woodfield University

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate. Rochville University AND Adisonhighschool AND Corllins University Review

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the DDL to generate the table to store the next id value for my custom id is only created once and does not check the column name value for each class. For my id generator there is a separate column used for each table in the database, so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding, but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

Chris Nicola — Sat, 03 Apr 2010 18:14:59 GMT
Revision 6 posted to How to by Chris Nicola on 03/04/2010 03:14:59 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the DDL to generate the table to store the next id value for my custom id is only created once and does not check the column name value for each class. For my id generator there is a separate column used for each table in the database, so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding, but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

Chris Nicola — Fri, 25 Dec 2009 00:31:36 GMT
Revision 5 posted to How to by Chris Nicola on 24/12/2009 09:31:36 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the code DDL to generate the table to store the next id value for a my custom id is only run created once per class (and then only on does not check the base column name value for each classif you are inheriting). For my id generator there is a separate column used for each table in the database. So, for so this was a problem. For example, the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding., but I was only getting one column (this appears to be a problem with hilo and SchemaExport, you can currently only have one column per database)

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

Chris Nicola — Fri, 25 Dec 2009 00:25:51 GMT
Revision 4 posted to How to by Chris Nicola on 24/12/2009 09:25:51 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the code to generate the table for a custom id is only run once per class (and then only on the base class if you are inheriting). For my id generator there is a separate column used for each table in the database. So, for example the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding.

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

Chris Nicola — Fri, 25 Dec 2009 00:18:06 GMT
Revision 3 posted to How to by Chris Nicola on 24/12/2009 09:18:06 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.

As I discovered the code to generate the table for a custom id is only run once per class (and then only on the base class if you are inheriting). For my id generator there is a separate column used for each table in the database. So, for example the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding.

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

Chris Nicola — Thu, 03 Sep 2009 16:42:06 GMT
Revision 2 posted to How to by Chris Nicola on 03/09/2009 01:42:06 p.m.

Creating a custom id generator for nHibernate

Filed under: Mapping, Nhibernate, IIdentifierGenerator, IPersistentIdentifierGenerator, TableGenerator, FluentNH

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.


One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.



As I discovered the code to generate the table for a custom id is only run once per class (and then only on the base class if you are inheriting). For my id generator there is a separate column used for each table in the database. So, for example the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding.

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Creating a custom id generator for nHibernate

Chris Nicola — Thu, 03 Sep 2009 16:41:21 GMT
Revision 1 posted to How to by Chris Nicola on 03/09/2009 01:41:21 p.m.

I originally blogged about this here and here on my blog but Fabio suggested I add these posts to the Forge, so here I am. I have to say I am a little exited to make my first contribution to the Wiki [H]. I will try to add a bit more to them and show some examples that do not use the TableGenerator class but directly implement IIdentifierGenerator . Please let me know if there are any mistakes or anything else you want to see.

Before beginning I recommend that you download the NH source code and take a quick look at the TableGenerator , IIdentifierGenerator and IPersistentIdentifierGenerator classes as you will be working with these classes and interfaces to implement your custom generator.

Part 1: Inheriting from TableGenerator class

Currently I am doing some work developing a utility that imports securities data into a fairly old legacy database. It is still SQL but the database and software havn't been updated in about 15 years (maybe more) and never will be again.

The original application for this database uses a primitive hilo-style ID generator mechanism. Tt simply queries an integer value from a table in the database and increments it, then it adds a fixed value to it and uses that as the next unique ID. It doesn't seem very optimal, but that's how it works and there's no changing it.

It isn't complex, but it also isn't one of the identity strategies available in nHibernate and I fully intend to use nHibernate.

So what to do? One option would be to set generator="assigned" and do it all myself, assigning the ID using ADO.Net directly or something similar... but what fun would that be? No, I've decided to take a peak at the nHibernate code and learn to extend it. Read on to find out how to create a custom class that inherits from IIdentifierGenerator to implement your own custom ID generator strategy for nHibernate.

One of the beautiful things about nHibernate the ability to extend it. You can extend its functionality without ever touching their source code.

It was very easy to locate the classes responsible for ID generation in the NHibernate.ID namespace. It was also clear immediately that most classes inherited from IIdentifierGenerator. I also knew that my strategy was similar to the procedure that hilo implements so I started with TableHiLoGenerator which inherts from TableGenerator.

After playing around with this for a while and trying different things, it was clear that TableGenerator, basically takes a tablename and columnname from the configuration, reads a value, increments it and passes it on as an ID. Voila! That was almost exactly what I needed to do with little else to change. I was quickly able to create my own class inheriting from TableGenerator

public class FDPSequence : TableGenerator

{

    private const Int32 SeedValue = 1048576;

    private static readonly ILog Log = LogManager.GetLogger(typeof(FDPSequence));

    public override object Generate(ISessionImplementor session, object obj)

    {

        int counter = Convert.ToInt32(base.Generate(session, obj));

        return counter + SeedValue + 1;

    }

}

Not much to that is there? Now that is a fairly simple case, but even getting more complex isn't much harder than that. You can implement IIdentifierGenerator directly and create something far more customized. TableGenerator actually implements IPersistentIdentifierGenerator which is an interface for identifiers which need to write and updated value to the database. However, since nHibernate provides so many versatile and inheritable base class generators that you will likely get by with inheriting one of those and extending it as I did.

In order to use this custom generator class I setup my configuration to use it. Using Fluent I wrote a mapping like this:

public class InvestSpecMap : FDPEntityBaseMap<InvestSpec>

{

    public InvestSpecMap()

    {

        WithTable("InvestSpec");

        Id(x => x.Id).ColumnName(tablename + "ID")

            .SetGeneratorClass(typeof(FDPGenerator.FDPSequence).AssemblyQualifiedName)

            .AddGeneratorParam("table", "zSysCounters") //Name of the ID counter table

            .AddGeneratorParam("column", "InvestSpec"); //ID counter column for this table

        Map(x => x.AnnualDividend).ColumnName("AnnlzdDiv");

        Map(x => x.AssetClass);

        Map(x => x.CurrencyType);

        Map(x => x.CusipNumber).ColumnName("CusipNum");

        Map(x => x.DividendFreq).ColumnName("DivFrequency");

        Map(x => x.FullName);

        Map(x => x.MaturityDate).ColumnName("MaturityDt");

        Map(x => x.PriceAsOf).ColumnName("PriceAsOfDt");

        Map(x => x.ShortName).ColumnName("AbbrName");

        Map(x => x.TaxTreatment);

        Map(x => x.TickerSymbol);

        Map(x => x.Type);

        Map(x => x.UnitPrice);

    }

}

You can do the same with XML mappings just declare the assembly and class as you usually would in XML. This is actually the first time I've used FluentNH.

What is great about this is that even when testing my mappings with SQLLite, SchemaExport is actually able to create the identity table based on the tablename and columnname properties in the nHibernate configuration. The main benefit here however is that identity generation remains transparent to the rest of my application. Also doing something cool with nHibernate, that's priceless of course

Part 2: Stealing from TableGenerator and controlling DDL generation

A while ago I posted about writing a custom id generator using nHibernate and extending one of the existing Generator classes nHibernate provides. This was done to support working with a legacy database which uses a custom id generation strategy. One thing I like to do with all my apps is write some basic CRUD tests to make sure my mappings and queries are all working properly.

To do this I use Oren's approach of creating a temporary in-memory database using SQLite to work with. This involves using the SchemaExport tool in nHibernate to generate the DDL to create the database. If you are using a table generator strategy it also needs to create the table and columns for the custom id generator. In some cases you may need to customize the DDL for your Id table.



As I discovered the code to generate the table for a custom id is only run once per class (and then only on the base class if you are inheriting). For my id generator there is a separate column used for each table in the database. So, for example the Price table has a column in the Counter table called Price to store it's counter and the Holding table has a column called Holding.

The TableGenerator class supports two parameters which are set in the HBM files (or using fluent) tablename and columnname which set the table and column names used for the id counter. If you have a copy of the nHibernate source code you will see that the TableGenerator class calls SqlCreateStrings()and SqlDropString() to create and drop the table for the id generator. Unfortunately, as I mentioned above this is only called once, and so it only creates one table with one column for whichever mapping is handled first.

In order to fix this I had to copy the TableGenerator class (yes, yes, I know copy-paste is bad form) and modify those functions. I also added a third parameter allcolumnnames in which I can provide a comma separated list of all the columns the table needs to have (one per table in my database). The SqlCreateStrings()is simple changed to:

public string[] SqlCreateStrings(Dialect dialect) {

string create = "create table " + tableName + " (";

string insert = "insert into " + tableName + " values (";

foreach (string s in allcolumns.Split(',')) {

create += " " + s + " " + dialect.GetTypeName(columnSqlType) + ",";

insert += " 1,";

}

create = create.Trim(',') + " )";

insert = insert.Trim(',') + " )";

return new[] {create, insert};

}

(Yes, yes, I know I should have learned from my last post and used a StringBuilder here as I pointed out in my last post, but seriously, this method will only ever be called once)

Now when it is called it will create the correct table with all the columns I need. A couple of example mappings for the database in FluentNH are shown below:

public InvestSpecMap() {

WithTable("InvestSpec");

Id(x => x.Id).ColumnName("InvestSpecID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestSpec"); //ID counter column name

public PriceMap() {

WithTable("InvestPrice");

Id(x => x.Id).ColumnName("InvestPriceID")

.SetGeneratorClass(typeof (FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", "InvestSpec, InvestPrice")

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", "InvestPrice"); //ID counter column name

To be completely "clean code" and avoid repeating myself I should probably factor out the Id() code into a method in an inhereted base class so I can call it from each mapping class like this:

protected void SetIdGenerator(string tablename) {

Id(x => x.Id).ColumnName(TableName + "Id")

.SetGeneratorClass(typeof(FdpSequenceGen).AssemblyQualifiedName)

.AddGeneratorParam("allcolumns", AllColumns)

.AddGeneratorParam("table", "zSysCounters") //ID counter table name

.AddGeneratorParam("column", TableName); //ID counter column name

}

Now I can unit test using a temporary in-memory SQLite database and all my tests are passing.

Checking if an Unloaded Collection Contains Elements

Ricardo Peres — Fri, 18 Nov 2011 15:35:52 GMT
Current revision posted to How to by Ricardo Peres on 18/11/2011 12:35:52 p.m.

If you want to know if an unloaded collection in an entity contains elements, or count them, without actually loading them, you need to use a custom query; that is because the Count property (if the collection is not mapped with lazy=”extra”) and the LINQ Count() andAny() methods force the whole collection to be loaded.

You can use something like these two methods, one for checking if there are any values, the other for actually counting them:

public static Boolean Exists(this ISession session, IEnumerable collection)

{

if (collection is IPersistentCollection)

{

IPersistentCollection col = collection as IPersistentCollection;

if (col.WasInitialized == false)

{

String[] roleParts = col.Role.Split('.');

String ownerTypeName = String.Join(".", roleParts, 0, roleParts.Length - 1);

String ownerCollectionName = roleParts.Last();

String hql = "select 1 from " + ownerTypeName + " it where it.id = :id and exists elements(it." + ownerCollectionName + ")";

Boolean exists = session.CreateQuery(hql).SetParameter("id", col.Key).List().Count == 1;

return (exists);

}

}

return ((collection as IEnumerable).OfType<Object>().Any());

}

public static Int64 Count(this ISession session, IEnumerable collection)

{

if (collection is IPersistentCollection)

{

IPersistentCollection col = collection as IPersistentCollection;

if (col.WasInitialized == false)

{

String[] roleParts = col.Role.Split('.');

String ownerTypeName = String.Join(".", roleParts, 0, roleParts.Length - 1);

String ownerCollectionName = roleParts.Last();

String hql = "select count(elements(it." + ownerCollectionName + ")) from " + ownerTypeName + " it where it.id = :id";

Int64 count = session.CreateQuery(hql).SetParameter("id", col.Key).UniqueResult<Int64>();

return (count);

}

}

return ((collection as IEnumerable).OfType<Object>().Count());

}

Here's how:

MyEntity entity = session.Load(100);

if (session.Exists(entity.SomeCollection))

{

Int32 count = session.Count(entity.SomeCollection);

//...

}

Localization techniques

brendan2452 — Sat, 29 Oct 2011 01:07:45 GMT
Current revision posted to How to by brendan2452 on 28/10/2011 10:07:45 p.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the [[howtonh:stuffynoseremedy.net/stuffy-nose-remedy/|stuffy nose remedy]] mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

John Davidson — Fri, 28 Oct 2011 14:13:21 GMT
Revision 13 posted to How to by John Davidson on 28/10/2011 11:13:21 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.Best Online Casino

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

liliasmit — Fri, 28 Oct 2011 13:56:54 GMT
Revision 12 posted to How to by liliasmit on 28/10/2011 10:56:54 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database. Best Online Casino

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

John Davidson — Wed, 06 Jul 2011 13:22:53 GMT
Revision 11 posted to How to by John Davidson on 06/07/2011 10:22:53 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

ThisMBA Project reports second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mappingauto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

MBA Project reports — Wed, 06 Jul 2011 04:59:56 GMT
Revision 10 posted to How to by MBA Project reports on 06/07/2011 01:59:56 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This MBA Project reports second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

John Davidson — Fri, 01 Jul 2011 10:41:47 GMT
Revision 9 posted to How to by John Davidson on 01/07/2011 07:41:47 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search DUI Lawyer in huntington Beach and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

John Davidson — Fri, 01 Jul 2011 10:41:12 GMT
Revision 8 posted to How to by John Davidson on 01/07/2011 07:41:12 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.Mustuniversity | Must University

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.Must University Accredited | Mustuniversity | Must University

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

LCD HDTV

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search DUI Lawyer in huntington Beach and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

Criminal Defense Lawyer in Long Beach — Fri, 01 Jul 2011 07:43:11 GMT
Revision 7 posted to How to by Criminal Defense Lawyer in Long Beach on 01/07/2011 04:43:11 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns. Mustuniversity | Must University

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database. Must University Accredited | Mustuniversity | Must University

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

LCD HDTV

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search DUI Lawyer in huntington Beach and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

markweee — Wed, 30 Mar 2011 11:47:46 GMT
Revision 6 posted to How to by markweee on 30/03/2011 08:47:46 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns. Mustuniversity | Must University

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database. Must University Accredited | Mustuniversity | Must University

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

LCD HDTV

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

mikeon098 — Fri, 24 Sep 2010 17:18:41 GMT
Revision 5 posted to How to by mikeon098 on 24/09/2010 02:18:41 p.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

LCD HDTV

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

tcook23 — Thu, 26 Aug 2010 12:35:37 GMT
Revision 4 posted to How to by tcook23 on 26/08/2010 09:35:37 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

LCD HDTV

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

mike3050 — Fri, 28 May 2010 12:41:41 GMT
Revision 3 posted to How to by mike3050 on 28/05/2010 09:41:41 a.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping auto insurance quotes)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

Marc Climent — Tue, 16 Mar 2010 15:27:42 GMT
Revision 2 posted to How to by Marc Climent on 16/03/2010 12:27:42 p.m.

Localization techniques

Filed under: IUserType, Filters, l18n, localization, property

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary (internally) but we choose to expose it as a String developing the getter (in Fabio's post) to make it easier for the user.

Alternatively, you can create your our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method. This, as well, can be exposed as a string through the proper getter.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

The entity property can't be a string

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Localization techniques

Marc Climent — Tue, 16 Mar 2010 12:18:25 GMT
Revision 1 posted to How to by Marc Climent on 16/03/2010 09:18:25 a.m.

This page is a summary of the two main different approaches found all around the web on Property Localization using NHibernate, based on a post in spanish on my own blog.

There are roughly two main paths

Method 1: Using a custom IUserType

This method is exposed thoroughly in a Fabio Maulo`s post called Localized Property with NHibernate, in which he discusses the use of the LocalizablePropertyType found in uNhAddIns.

It is based on implementing IUserType, providing methods to serialize and deserialize the property. This way, we make use of NHibernate extensibility to provide a seamless mechanism to store and retrieve the property in a field of the database.

In the example, the property is a Dictionary but we can create our own class to contain all the translations and ease the addition and removal of them as well as properties to have quick access to the current localization string based on Thread.CurrentThread.CurrentCulture. In some of the proposals in the second method discussed there are examples of such classes that can be easily adapted to this method.

Pros:

Simple and easy

Data stored in the same table as the entity

Fairly transparent, specially if a custom object is used to simplify the access to the translations

Cons:

The value of the field is not understandable by the DBMS (no indexing, sorting or whatever)

The entity property can't be a string

Method 2: Using several tables

This second method has many variants, but all of them use one or more tables to store the translations, making them visible to the DBMS.

Proposal 2.1: Localizing NHibernate: Contextual Parameters by Ayende

This is an interesting approach, quite simple in explanation but uses a couple of advanced NHibernate features such as formulas and filters. The advantage is that the property of the entity is a simple string and the selection of the language to load is made through the formula based on a session parameter.

Proposal 2.2: Create a multi languaged domain model with NHibernate and C# by Michal @ WebDevBros

This one uses a nice crafted class to store and retrieve localization information and a couple of tables, one containing the dictionaries that create the relationship between the entity and the translations, that are accessed via a <map> in the mapping. (NOTE: I have not tested it, and he says that you can map several properties in the same entity with this method but not with the provided mapping)

The class called PhraseDictionary can be easily used through a IUserType with the first method.

Proposal 2.3: Mapping translations in NHibernate by Siim Viikman

The method proposed here is very similar to the former one, in this case using three tables, but that's up to you. It explains how to do the mapping using an Id different from the PK (which can't be done at this moment using Fluent NHibernate, just in case you want to).

The PhraseDictionary has been replaced by the Translation class, but essentially are the same, holders of the translation dictionary. Can be adapted as well to use it with method 1.

Proposal 2.4: Localizable entities with Nhibernate part 1 (part 2 and part 3) by Alkampfer

A very thorough example. It maps only one property per entity, simplifying the mappings and the table structure and can be more than enough for many solutions. It discusses a lot about a Registry object to hold the current locale, but you can change that to rely in Thread.CurrentThread.CurrentCulture and simplify a little bit.

Pros:

DBMS-aware solution

Cons:

More complex mappings

More complex data structure

Conclusions

Localization is painful in most scenarios and some guidelines can be followed:

If you don't really need that a property is localizable, don't make it localizable. Ok, in most cases is not your decision. If you have choice, think it twice or thrice before making a property localizable.

If you don't need to use DBMS capabilities on the field (such as sorting), go for the first method, it's easy to to the IUserType and the mappings and as well as the serialization is well tested won't give much trouble

If you need DBMS capabilities, in most cases only some properties will need this, so instead of embracing blindly the second method, think if a mixed solution is not simpler and better for you. (Was in my case)

As a side note, if you need to index the property, think of using NHibernate.Search and Lucene.NET using method 1 and a custom Bridge implementation to store the localizations in the index.

Finally, thanks to all that participated in NHUsers discussion on the topic.

Configure Log4Net for use with NHibernate

John Davidson — Mon, 19 Sep 2011 21:52:01 GMT
Current revision posted to How to by John Davidson on 19/09/2011 06:52:01 p.m.

Configure Log4Net for use with NHibernate

Filed under: logging, log4net

The Log4Net assembly is distributed with NHibernate binaries.

If you are not sure about details of the configuration shown below please refer to this documentation.

Running without Log4Net

If you only want NHibernate to log the queries it sends to the data source when running unit tests you don't have to configure Log4Net at all. It suffices to add the show_sql key to the NHibernate configuration. If you are using a separate xml file to configure NHibernate (e.g. the hibernate.cfg.xml) then its content might look similar to the one below

I am not too lazy to write an academic paper. I just do not have time for writing. Thus, I need to go to the essay writing service to get custom papers, which are composed by the best writing experts. I understand that a lot of people cannot become successful without writing assistance.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
<property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
<property name="connection.connection_string">
Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
</property>
<property name="show_sql">true</property>
</session-factory>
</hibernate-configuration>

Now when running any unit test that involves NHibernate the queries generated by NHibernate will be logged in the output window (be it the unit test runner of Resharper or be it the Output Window of Visual Studio when you useTestDriven).

Logging with Log4Net

If you want to use Log4Net to collect logging information generated by NHibernate you have to add the necessary configuration to the config file of your application. If you want to log to two different targets (e.g. to the console and to a file) the relevant sections in your config file might look like followsThesis Writing AND Dissertation Writing AND Essay Writing:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>

<section name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>




<log4net debug="false">


<appender name="trace"
type="log4net.Appender.TraceAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="console"
type="log4net.Appender.ConsoleAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="rollingFile"
type="log4net.Appender.RollingFileAppender,log4net" >

<param name="File" value="log.txt" />
<param name="AppendToFile" value="false" />
<param name="RollingStyle" value="Date" />
<param name="DatePattern" value="yyyy.MM.dd" />
<param name="StaticLogFileName" value="true" />

<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d [%t] %-5p %c - %m%n" />
</layout>
</appender>


<root>
<priority value="DEBUG" />
<appender-ref ref="console" />
</root>

</log4net>
</configuration>

Here I define that all output with a priority of at least DEBUG goes to the console.

Now I have to tell my application that I want to use Log4Net. I can do that with an assembly level attribute. That is, you have to put the following code snippet somewhere in your application (e.g. the "Global. asax" if you are building a web application)

// Configure log4net using the .config file
[assembly: log4net.Config.XmlConfigurator(Watch = true)]

having done do we can now run a first unit test that accesses the database via NHibernate. The output generated by Log4Net in the unit test runner is similar to this

2008-07-02 08:40:07,249 INFO NHibernate 2.0.0.4000 (2.0.0.4000)
2008-07-02 08:40:07,251 INFO hibernate-configuration section not found in application configuration file
2008-07-02 08:40:07,254 INFO Bytecode provider name : lcg
2008-07-02 08:40:07,257 INFO Using reflection optimizer
2008-07-02 08:40:08,515 DEBUG connection.provider=NHibernate.Connection.DriverConnectionProvider
2008-07-02 08:40:08,516 DEBUG dialect=NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:08,517 DEBUG connection.driver_class=NHibernate.Driver.SqlClientDriver
2008-07-02 08:40:08,517 DEBUG connection.connection_string=Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
2008-07-02 08:40:08,518 DEBUG show_sql=false
2008-07-02 08:40:08,522 DEBUG properties: System.Collections.Generic.Dictionary`2[System.String,System.String]
2008-07-02 08:40:08,526 INFO Mapping resource: LoggingSample.Person.hbm.xml
2008-07-02 08:40:08,872 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,425 INFO Mapping class: LoggingSample.Person -> Person
2008-07-02 08:40:11,537 DEBUG Mapped property: Id -> Id, type: Int32
2008-07-02 08:40:11,612 DEBUG Mapped property: LastName -> LastName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: FirstName -> FirstName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: Birthdate -> Birthdate, type: DateTime
2008-07-02 08:40:11,632 INFO checking mappings queue
2008-07-02 08:40:11,634 INFO processing one-to-many association mappings
2008-07-02 08:40:11,634 INFO processing one-to-one association property references
2008-07-02 08:40:11,634 INFO processing foreign key constraints
2008-07-02 08:40:11,712 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,716 INFO Using dialect defined converter
...
2008-07-02 08:40:12,410 DEBUG Static SQL for entity: LoggingSample.Person
2008-07-02 08:40:12,411 DEBUG Version select: SELECT Id FROM Person WHERE Id = ?
2008-07-02 08:40:12,412 DEBUG Snapshot select: SELECT person_.Id, person_.LastName as LastName0_, person_.FirstName as FirstName0_, person_.Birthdate as Birthdate0_ FROM Person person_ WHERE person_.Id=?
...

as you can see LOADS of information.

To tune the generated logging information a little bit we can filter the output generated by NHibernate by putting the following configuration section into our config file (put them just after the root section inside the log4net node)

<logger name="NHibernate">
<level value="WARN" />
</logger>

<logger name="NHibernate.SQL">
<level value="DEBUG" />
</logger>

Obviously NHibernate defines two different loggers NHibernate and NHibernate.SQL. The first one receives all logging output that NHibernate generates where as the second one only receives the sql statements generated by NHibernate.

With the above settings in place the output generated is reduced to

2008-07-02 08:48:58,636 DEBUG select person0_.Id as Id0_,
person0_.LastName as LastName0_,
person0_.FirstName as FirstName0_,
person0_.Birthdate as Birthdate0_
from Person person0_

That's what we want. Only if we have some weird problems we need to change the priority level of the NHibernate filter to say INFO or DEBUG.

Configure Log4Net for use with NHibernate

barbarasmith22 — Mon, 19 Sep 2011 11:10:23 GMT
Revision 5 posted to How to by barbarasmith22 on 19/09/2011 08:10:23 a.m.

Configure Log4Net for use with NHibernate

Filed under: logging, log4net

The Log4Net assembly is distributed with NHibernate binaries.

If you are not sure about details of the configuration shown below please refer to this documentation.

Running without Log4Net

If you only want NHibernate to log the queries it sends to the data source when running unit tests you don't have to configure Log4Net at all. It suffices to add the show_sql key to the NHibernate configuration. If you are using a separate xml file to configure NHibernate (e.g. the hibernate.cfg.xml) then its content might look similar to the one below Term Paper Writing AND Research Paper Writing

I am not too lazy to write an academic paper. I just do not have time for writing. Thus, I need to go to the essay writing service to get custom papers, which are composed by the best writing experts. I understand that a lot of people cannot become successful without writing assistance.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
<property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
<property name="connection.connection_string">
Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
</property>
<property name="show_sql">true</property>
</session-factory>
</hibernate-configuration>

Now when running any unit test that involves NHibernate the queries generated by NHibernate will be logged in the output window (be it the unit test runner of Resharper or be it the Output Window of Visual Studio when you useTestDriven).

Logging with Log4Net

If you want to use Log4Net to collect logging information generated by NHibernate you have to add the necessary configuration to the config file of your application. If you want to log to two different targets (e.g. to the console and to a file) the relevant sections in your config file might look like follows Thesis Writing AND Dissertation Writing AND Essay Writing

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>

<section name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>




<log4net debug="false">


<appender name="trace"
type="log4net.Appender.TraceAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="console"
type="log4net.Appender.ConsoleAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="rollingFile"
type="log4net.Appender.RollingFileAppender,log4net" >

<param name="File" value="log.txt" />
<param name="AppendToFile" value="false" />
<param name="RollingStyle" value="Date" />
<param name="DatePattern" value="yyyy.MM.dd" />
<param name="StaticLogFileName" value="true" />

<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d [%t] %-5p %c - %m%n" />
</layout>
</appender>


<root>
<priority value="DEBUG" />
<appender-ref ref="console" />
</root>

</log4net>
</configuration>

Here I define that all output with a priority of at least DEBUG goes to the console.

Now I have to tell my application that I want to use Log4Net. I can do that with an assembly level attribute. That is, you have to put the following code snippet somewhere in your application (e.g. the "Global. asax" if you are building a web application)

// Configure log4net using the .config file
[assembly: log4net.Config.XmlConfigurator(Watch = true)]

having done do we can now run a first unit test that accesses the database via NHibernate. The output generated by Log4Net in the unit test runner is similar to this

2008-07-02 08:40:07,249 INFO NHibernate 2.0.0.4000 (2.0.0.4000)
2008-07-02 08:40:07,251 INFO hibernate-configuration section not found in application configuration file
2008-07-02 08:40:07,254 INFO Bytecode provider name : lcg
2008-07-02 08:40:07,257 INFO Using reflection optimizer
2008-07-02 08:40:08,515 DEBUG connection.provider=NHibernate.Connection.DriverConnectionProvider
2008-07-02 08:40:08,516 DEBUG dialect=NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:08,517 DEBUG connection.driver_class=NHibernate.Driver.SqlClientDriver
2008-07-02 08:40:08,517 DEBUG connection.connection_string=Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
2008-07-02 08:40:08,518 DEBUG show_sql=false
2008-07-02 08:40:08,522 DEBUG properties: System.Collections.Generic.Dictionary`2[System.String,System.String]
2008-07-02 08:40:08,526 INFO Mapping resource: LoggingSample.Person.hbm.xml
2008-07-02 08:40:08,872 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,425 INFO Mapping class: LoggingSample.Person -> Person
2008-07-02 08:40:11,537 DEBUG Mapped property: Id -> Id, type: Int32
2008-07-02 08:40:11,612 DEBUG Mapped property: LastName -> LastName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: FirstName -> FirstName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: Birthdate -> Birthdate, type: DateTime
2008-07-02 08:40:11,632 INFO checking mappings queue
2008-07-02 08:40:11,634 INFO processing one-to-many association mappings
2008-07-02 08:40:11,634 INFO processing one-to-one association property references
2008-07-02 08:40:11,634 INFO processing foreign key constraints
2008-07-02 08:40:11,712 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,716 INFO Using dialect defined converter
...
2008-07-02 08:40:12,410 DEBUG Static SQL for entity: LoggingSample.Person
2008-07-02 08:40:12,411 DEBUG Version select: SELECT Id FROM Person WHERE Id = ?
2008-07-02 08:40:12,412 DEBUG Snapshot select: SELECT person_.Id, person_.LastName as LastName0_, person_.FirstName as FirstName0_, person_.Birthdate as Birthdate0_ FROM Person person_ WHERE person_.Id=?
...

as you can see LOADS of information.

To tune the generated logging information a little bit we can filter the output generated by NHibernate by putting the following configuration section into our config file (put them just after the root section inside the log4net node)

<logger name="NHibernate">
<level value="WARN" />
</logger>

<logger name="NHibernate.SQL">
<level value="DEBUG" />
</logger>

Obviously NHibernate defines two different loggers NHibernate and NHibernate.SQL. The first one receives all logging output that NHibernate generates where as the second one only receives the sql statements generated by NHibernate.

With the above settings in place the output generated is reduced to

2008-07-02 08:48:58,636 DEBUG select person0_.Id as Id0_,
person0_.LastName as LastName0_,
person0_.FirstName as FirstName0_,
person0_.Birthdate as Birthdate0_
from Person person0_

That's what we want. Only if we have some weird problems we need to change the priority level of the NHibernate filter to say INFO or DEBUG.

Configure Log4Net for use with NHibernate

markweee — Wed, 30 Mar 2011 11:21:17 GMT
Revision 4 posted to How to by markweee on 30/03/2011 08:21:17 a.m.

Configure Log4Net for use with NHibernate

Filed under: logging, log4net

The Log4Net assembly is distributed with NHibernate binaries.

If you are not sure about details of the configuration shown below please refer to this documentation.

Running without Log4Net

If you only want NHibernate to log the queries it sends to the data source when running unit tests you don't have to configure Log4Net at all. It suffices to add the show_sql key to the NHibernate configuration. If you are using a separate xml file to configure NHibernate (e.g. the hibernate.cfg.xml) then its content might look similar to the one below Term Paper Writing AND Research Paper Writing

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
<property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
<property name="connection.connection_string">
Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
</property>
<property name="show_sql">true</property>
</session-factory>
</hibernate-configuration>

Now when running any unit test that involves NHibernate the queries generated by NHibernate will be logged in the output window (be it the unit test runner of Resharper or be it the Output Window of Visual Studio when you useTestDriven).

Logging with Log4Net

If you want to use Log4Net to collect logging information generated by NHibernate you have to add the necessary configuration to the config file of your application. If you want to log to two different targets (e.g. to the console and to a file) the relevant sections in your config file might look like follows Thesis Writing AND Dissertation Writing AND Essay Writing

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>

<section name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>




<log4net debug="false">


<appender name="trace"
type="log4net.Appender.TraceAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="console"
type="log4net.Appender.ConsoleAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="rollingFile"
type="log4net.Appender.RollingFileAppender,log4net" >

<param name="File" value="log.txt" />
<param name="AppendToFile" value="false" />
<param name="RollingStyle" value="Date" />
<param name="DatePattern" value="yyyy.MM.dd" />
<param name="StaticLogFileName" value="true" />

<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d [%t] %-5p %c - %m%n" />
</layout>
</appender>


<root>
<priority value="DEBUG" />
<appender-ref ref="console" />
</root>

</log4net>
</configuration>

Here I define that all output with a priority of at least DEBUG goes to the console.

Now I have to tell my application that I want to use Log4Net. I can do that with an assembly level attribute. That is, you have to put the following code snippet somewhere in your application (e.g. the "Global. asax" if you are building a web application)

// Configure log4net using the .config file
[assembly: log4net.Config.XmlConfigurator(Watch = true)]

having done do we can now run a first unit test that accesses the database via NHibernate. The output generated by Log4Net in the unit test runner is similar to this

2008-07-02 08:40:07,249 INFO NHibernate 2.0.0.4000 (2.0.0.4000)
2008-07-02 08:40:07,251 INFO hibernate-configuration section not found in application configuration file
2008-07-02 08:40:07,254 INFO Bytecode provider name : lcg
2008-07-02 08:40:07,257 INFO Using reflection optimizer
2008-07-02 08:40:08,515 DEBUG connection.provider=NHibernate.Connection.DriverConnectionProvider
2008-07-02 08:40:08,516 DEBUG dialect=NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:08,517 DEBUG connection.driver_class=NHibernate.Driver.SqlClientDriver
2008-07-02 08:40:08,517 DEBUG connection.connection_string=Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
2008-07-02 08:40:08,518 DEBUG show_sql=false
2008-07-02 08:40:08,522 DEBUG properties: System.Collections.Generic.Dictionary`2[System.String,System.String]
2008-07-02 08:40:08,526 INFO Mapping resource: LoggingSample.Person.hbm.xml
2008-07-02 08:40:08,872 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,425 INFO Mapping class: LoggingSample.Person -> Person
2008-07-02 08:40:11,537 DEBUG Mapped property: Id -> Id, type: Int32
2008-07-02 08:40:11,612 DEBUG Mapped property: LastName -> LastName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: FirstName -> FirstName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: Birthdate -> Birthdate, type: DateTime
2008-07-02 08:40:11,632 INFO checking mappings queue
2008-07-02 08:40:11,634 INFO processing one-to-many association mappings
2008-07-02 08:40:11,634 INFO processing one-to-one association property references
2008-07-02 08:40:11,634 INFO processing foreign key constraints
2008-07-02 08:40:11,712 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,716 INFO Using dialect defined converter
...
2008-07-02 08:40:12,410 DEBUG Static SQL for entity: LoggingSample.Person
2008-07-02 08:40:12,411 DEBUG Version select: SELECT Id FROM Person WHERE Id = ?
2008-07-02 08:40:12,412 DEBUG Snapshot select: SELECT person_.Id, person_.LastName as LastName0_, person_.FirstName as FirstName0_, person_.Birthdate as Birthdate0_ FROM Person person_ WHERE person_.Id=?
...

as you can see LOADS of information.

To tune the generated logging information a little bit we can filter the output generated by NHibernate by putting the following configuration section into our config file (put them just after the root section inside the log4net node)

<logger name="NHibernate">
<level value="WARN" />
</logger>

<logger name="NHibernate.SQL">
<level value="DEBUG" />
</logger>

Obviously NHibernate defines two different loggers NHibernate and NHibernate.SQL. The first one receives all logging output that NHibernate generates where as the second one only receives the sql statements generated by NHibernate.

With the above settings in place the output generated is reduced to

2008-07-02 08:48:58,636 DEBUG select person0_.Id as Id0_,
person0_.LastName as LastName0_,
person0_.FirstName as FirstName0_,
person0_.Birthdate as Birthdate0_
from Person person0_

That's what we want. Only if we have some weird problems we need to change the priority level of the NHibernate filter to say INFO or DEBUG.

Configure Log4Net for use with NHibernate

Dario Quintana — Fri, 17 Oct 2008 00:23:49 GMT
Revision 3 posted to How to by Dario Quintana on 16/10/2008 09:23:49 p.m.

Configure Log4Net for use with NHibernate

Filed under: logging, log4net

The Log4Net assebly assembly is distributed with NHibernate binaries.

If you are not sure about details of the configuration shown below please refer to this documentation.

Running without Log4Net

If you only want NHibernate to log the queries it sends to the data source when running unit tests you don't have to configure Log4Net at all. It suffices to add the show_sql key to the NHibernate configuration. If you are using a separate xml file to configure NHibernate (e.g. the hibernate.cfg.xml) then its content might look similar to the one below

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
<property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
<property name="connection.connection_string">
Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
</property>
<property name="show_sql">true</property>
</session-factory>
</hibernate-configuration>

Now when running any unit test that involves NHibernate the queries generated by NHibernate will be logged in the output window (be it the unit test runner of Resharper or be it the Output Window of Visual Studio when you useTestDriven).

Logging with Log4Net

If you want to use Log4Net to collect logging information generated by NHibernate you have to add the necessary configuration to the config file of your application. If you want to log to two different targets (e.g. to the console and to a file) the relevant sections in your config file might look like follows

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>

<section name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>




<log4net debug="false">


<appender name="trace"
type="log4net.Appender.TraceAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="console"
type="log4net.Appender.ConsoleAppender, log4net">
<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" />
</layout>
</appender>

<appender name="rollingFile"
type="log4net.Appender.RollingFileAppender,log4net" >

<param name="File" value="log.txt" />
<param name="AppendToFile" value="false" />
<param name="RollingStyle" value="Date" />
<param name="DatePattern" value="yyyy.MM.dd" />
<param name="StaticLogFileName" value="true" />

<layout type="log4net.Layout.PatternLayout,log4net">
<param name="ConversionPattern"
value="%d [%t] %-5p %c - %m%n" />
</layout>
</appender>


<root>
<priority value="DEBUG" />
<appender-ref ref="console" />
</root>

</log4net>
</configuration>

Here I define that all output with a priority of at least DEBUG goes to the console.

Now I have to tell my application that I want to use Log4Net. I can do that with an assembly level attribute. That is, you have to put the following code snippet somewhere in your application (e.g. the "Global. asax" if you are building a web application)

// Configure log4net using the .config file
[assembly: log4net.Config.XmlConfigurator(Watch = true)]

having done do we can now run a first unit test that accesses the database via NHibernate. The output generated by Log4Net in the unit test runner is similar to this

2008-07-02 08:40:07,249 INFO NHibernate 2.0.0.4000 (2.0.0.4000)
2008-07-02 08:40:07,251 INFO hibernate-configuration section not found in application configuration file
2008-07-02 08:40:07,254 INFO Bytecode provider name : lcg
2008-07-02 08:40:07,257 INFO Using reflection optimizer
2008-07-02 08:40:08,515 DEBUG connection.provider=NHibernate.Connection.DriverConnectionProvider
2008-07-02 08:40:08,516 DEBUG dialect=NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:08,517 DEBUG connection.driver_class=NHibernate.Driver.SqlClientDriver
2008-07-02 08:40:08,517 DEBUG connection.connection_string=Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;
2008-07-02 08:40:08,518 DEBUG show_sql=false
2008-07-02 08:40:08,522 DEBUG properties: System.Collections.Generic.Dictionary`2[System.String,System.String]
2008-07-02 08:40:08,526 INFO Mapping resource: LoggingSample.Person.hbm.xml
2008-07-02 08:40:08,872 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,425 INFO Mapping class: LoggingSample.Person -> Person
2008-07-02 08:40:11,537 DEBUG Mapped property: Id -> Id, type: Int32
2008-07-02 08:40:11,612 DEBUG Mapped property: LastName -> LastName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: FirstName -> FirstName, type: String
2008-07-02 08:40:11,614 DEBUG Mapped property: Birthdate -> Birthdate, type: DateTime
2008-07-02 08:40:11,632 INFO checking mappings queue
2008-07-02 08:40:11,634 INFO processing one-to-many association mappings
2008-07-02 08:40:11,634 INFO processing one-to-one association property references
2008-07-02 08:40:11,634 INFO processing foreign key constraints
2008-07-02 08:40:11,712 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect
2008-07-02 08:40:11,716 INFO Using dialect defined converter
...
2008-07-02 08:40:12,410 DEBUG Static SQL for entity: LoggingSample.Person
2008-07-02 08:40:12,411 DEBUG Version select: SELECT Id FROM Person WHERE Id = ?
2008-07-02 08:40:12,412 DEBUG Snapshot select: SELECT person_.Id, person_.LastName as LastName0_, person_.FirstName as FirstName0_, person_.Birthdate as Birthdate0_ FROM Person person_ WHERE person_.Id=?
...

as you can see LOADS of information.

To tune the generated logging information a little bit we can filter the output generated by NHibernate by putting the following configuration section into our config file (put them just after the root section inside the log4net node)

<logger name="NHibernate">
<level value="WARN" />
</logger>

<logger name="NHibernate.SQL">
<level value="DEBUG" />
</logger>

Obviously NHibernate defines two different loggers NHibernate and NHibernate.SQL. The first one receives all logging output that NHibernate generates where as the second one only receives the sql statements generated by NHibernate.

With the above settings in place the output generated is reduced to

2008-07-02 08:48:58,636 DEBUG select person0_.Id as Id0_,
person0_.LastName as LastName0_,
person0_.FirstName as FirstName0_,
person0_.Birthdate as Birthdate0_
from Person person0_

That's what we want. Only if we have some weird problems we need to change the priority level of the NHibernate filter to say INFO or DEBUG.

Configure Log4Net for use with NHibernate

Fabio Maulo — Sun, 07 Sep 2008 17:20:36 GMT
Revision 2 posted to How to by Fabio Maulo on 07/09/2008 02:20:36 p.m.

Configure Log4Net for use with NHibernate

Recently there was a question in the NHUser group about how to configure
The Log4Net to log the queries generated by assebly is distributed with NHibernate . First of all: you can get Log4Net here. There you also find the documentationbinaries.

If you are not sure about details of the configuration shown below please refer to this documentation.

Running without Log4Net

If you only want NHibernate to log the queries it sends to the data source when running unit tests you don't have to configure Log4Net at all. It suffices to add the show_sql key to the NHibernate configuration. If you are using a separate xml file to configure NHibernate (e.g. the hibernate.cfg.xml) then its content might look similar to the one below

<?xml version=version="1.0" encoding=encoding="utf-8" ?><o:p></o:p> <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2"><o:p></o:p>"urn:nhibernate-configuration-2.2"> <session-factory><o:p></o:p> <property name="connection.provider">"connection.provider">NHibernate.Connection.DriverConnectionProvider</property><o:p></o:p> <property name="dialect">"dialect">NHibernate.Dialect.MsSql2005Dialect</property><o:p></o:p> <property name="connection.driver_class">"connection.driver_class">NHibernate.Driver.SqlClientDriver</property><o:p></o:p> <property name="connection.connection_string">"connection.connection_string"> Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI; </property>   > <property name="show_sql">"show_sql">true</property><o:p></o:p> </session-factory><o:p></o:p> </hibernate-configuration><o:p></o:p>

Now when running any unit test that involves NHibernate the queries generated by NHibernate will be logged in the output window (be it the unit test runner of Resharper or be it the Output Window of Visual Studio when you useTestDriven)useTestDriven).

Logging with Log4Net

If you want to use Log4Net to collect logging information generated by NHibernate you have to add the necessary configuration to the config file of your application. If you want to log to two different targets (e.g. to the console and to a file) the relevant sections in your config file might look like follows

<configuration>

...

<configSections>

    <section name=

<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections>  <section name="log4net"type= type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />

</configSections>

<log4net>

    <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender, </configSections>   <log4net ">

        <param name=debug="false">  <appender name="trace" type="log4net.Appender.TraceAppender, log4net"> <layout type="log4net.Layout.PatternLayout,log4net"> <param name="ConversionPattern"value="%d value="%d{ABSOLUTE} %p -5p %c{1}:%L - %m%n" />

      </layout>

    </appender>

    <appender name="RollingFile" type= </layout> </appender> <appender name="console" type="log4net.Appender.ConsoleAppender, log4net"> <layout type="log4net.Layout.PatternLayout,log4net"> <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p %c{1}:%L - %m%n" /> </layout> </appender> <appender name="rollingFile" type="log4net.Appender.RollingFileAppender,log4net" >

      <param name= <param name="File"value= value="log.txt" />

      <param name= <param name="AppendToFile"value="true" value="false" />

      <param name= <param name="RollingStyle" value="Date" /> <param name="DatePattern"value= value="yyyy.MM.dd" />

      <layout type="log4net.Layout.PatternLayout,log4net">

        <conversionPattern value= <param name="StaticLogFileName" value="true" /> <layout type="log4net.Layout.PatternLayout,log4net"> <param name="ConversionPattern" value="%d [%t] %p -5p %c - %m%n" />

      </layout>

    </appender>

    <root>

      <priority value= </layout> </appender>  <root> <priority value="DEBUG" />

      <appender-ref ref="ConsoleAppender" <appender-ref ref="console" />

    </root>

    ...

</configuration> </root> </log4net> </configuration>

Here I define that all output with a priority of at least DEBUG goes to the console.

Now I have to tell my application that I want to use Log4Net. I can do that with an assembly level attribute. That is, you have to put the following code snippet somewhere in your application (e.g. the "Global. asax" if you are building a web application)

// Configure log4net using the .config file [assembly: log4net.Config.XmlConfigurator(Watch = true)true)]

having done do we can now run a first unit test that accesses the database via NHibernate. The output generated by Log4Net in the unit test runner is similar to this

2008-07-02 08:40:07,249 INFO NHibernate 2.0.0.1001 2.0.0.4000 (2.0.0.1001)2.0.0.4000) 2008-07-02 08:40:07,251 INFO hibernate-configuration section not found in application configuration file 2008-07-02 08:40:07,254 INFO Bytecode provider name : lcg 2008-07-02 08:40:07,257 INFO Using reflection optimizer 2008-07-02 08:40:08,515 DEBUG connection.provider=NHibernate.Connection.DriverConnectionProvider 2008-07-02 08:40:08,516 DEBUG dialect=NHibernate.Dialect.MsSql2005Dialect 2008-07-02 08:40:08,517 DEBUG connection.driver_class=NHibernate.Driver.SqlClientDriver 2008-07-02 08:40:08,517 DEBUG connection.connection_string=Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI; 2008-07-02 08:40:08,518 DEBUG show_sql=false 2008-07-02 08:40:08,522 DEBUG properties: System.Collections.Generic.Dictionary`2[System.String,System.String] 2008-07-02 08:40:08,526 INFO Mapping resource: LoggingSample.Person.hbm.xml 2008-07-02 08:40:08,872 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect 2008-07-02 08:40:11,425 INFO Mapping class: LoggingSample.Person -> Person 2008-07-02 08:40:11,537 DEBUG Mapped property: Id -> Id, type: Int32 2008-07-02 08:40:11,612 DEBUG Mapped property: LastName -> LastName, type: String 2008-07-02 08:40:11,614 DEBUG Mapped property: FirstName -> FirstName, type: String 2008-07-02 08:40:11,614 DEBUG Mapped property: Birthdate -> Birthdate, type: DateTime 2008-07-02 08:40:11,632 INFO checking mappings queue 2008-07-02 08:40:11,634 INFO processing one-to-many association mappings 2008-07-02 08:40:11,634 INFO processing one-to-one association property references 2008-07-02 08:40:11,634 INFO processing foreign key constraints 2008-07-02 08:40:11,712 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect 2008-07-02 08:40:11,716 INFO Using dialect defined converter ... 2008-07-02 08:40:12,410 DEBUG Static SQL for entity: LoggingSample.Person 2008-07-02 08:40:12,411 DEBUG Version select: SELECT Id FROM Person WHERE Id = ? 2008-07-02 08:40:12,412 DEBUG Snapshot select: SELECT person_.Id, person_.LastName as LastName0_, person_.FirstName as FirstName0_, person_.Birthdate as Birthdate0_ FROM Person person_ WHERE person_.Id=? ...

as you can see LOADS of information.

To tune the generated logging information a little bit we can filter the output generated by NHibernate by putting the following configuration section into our config file (put them just after the root section inside the log4net node)

<logger name=

<logger name="NHibernate"additivity="false">

<level value="WARN"/>

<appender-ref ref="RollingFile" />

<appender-ref ref="ConsoleAppender" <level value="WARN" />

</logger>

<logger name= </logger> <logger name="NHibernate.SQL"additivity="false">

<level value="ALL"/>

<appender-ref ref="RollingFile" />

<appender-ref ref="ConsoleAppender" <level value="DEBUG" />

</logger> </logger>

Obviously NHibernate defines two different loggers NHibernate and NHibernate.SQL. The first one receives all logging output that NHibernate generates where as the second one only receives the sql statements generated by NHibernate.

With the above settings in place the output generated is reduced to

2008-07-02 08:48:58,636 DEBUG select person0_.Id as Id0_, person0_.LastName as LastName0_, person0_.FirstName as FirstName0_, person0_.Birthdate as Birthdate0_ from Person person0_

That's what we want. Only if we have some weird problems we need to change the priority level of the NHibernate filter to say INFO or DEBUG.

As usual you can find a demo solution here.

Configure Log4Net for use with NHibernate

gabriel.schenker — Sun, 07 Sep 2008 05:09:37 GMT
Revision 1 posted to How to by gabriel.schenker on 07/09/2008 02:09:37 a.m.

Recently there was a question in the NHUser group about how to configure Log4Net to log the queries generated by NHibernate. First of all: you can get Log4Net here. There you also find the documentation. If you are not sure about details of the configuration shown below please refer to this documentation.

Running without Log4Net

If you only want NHibernate to log the queries it sends to the data source when running unit tests you don't have to configure Log4Net at all. It suffices to add the show_sql key to the NHibernate configuration. If you are using a separate xml file to configure NHibernate (e.g. the hibernate.cfg.xml) then its content might look similar to the one below

<?xml version="1.0" encoding="utf-8" ?><o:p></o:p>

<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2"><o:p></o:p>

<session-factory><o:p></o:p>

    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property><o:p></o:p>

    <property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property><o:p></o:p>

    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property><o:p></o:p>

    <property name="connection.connection_string">Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;</property>

    <property name="show_sql">true</property><o:p></o:p>

</session-factory><o:p></o:p>

</hibernate-configuration><o:p></o:p>

Now when running any unit test that involves NHibernate the queries generated by NHibernate will be logged in the output window (be it the unit test runner of Resharper or be it the Output Window of Visual Studio when you useTestDriven).

Logging with Log4Net

If you want to use Log4Net to collect logging information generated by NHibernate you have to add the necessary configuration to the config file of your application. If you want to log to two different targets (e.g. to the console and to a file) the relevant sections in your config file might look like follows

<configuration>

...

<configSections>

    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />

</configSections>

<log4net>

    <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender, log4net">

      <layout type="log4net.Layout.PatternLayout, log4net">

        <param name="ConversionPattern" value="%d %p %m%n" />

      </layout>

    </appender>

    <appender name="RollingFile" type="log4net.Appender.RollingFileAppender,log4net" >

      <param name="File" value="log.txt" />

      <param name="AppendToFile" value="true" />

      <param name="DatePattern" value="yyyy.MM.dd" />

      <layout type="log4net.Layout.PatternLayout,log4net">

        <conversionPattern value="%d %p %m%n" />

      </layout>

    </appender>

    <root>

      <priority value="DEBUG" />

      <appender-ref ref="ConsoleAppender" />

    </root>

    ...

</configuration>

Here I define that all output with a priority of at least DEBUG goes to the console.

Now I have to tell my application that I want to use Log4Net. I can do that with an assembly level attribute. That is, you have to put the following code snippet somewhere in your application (e.g. the "Global. asax" if you are building a web application)

// Configure log4net using the .config file

[assembly: log4net.Config.XmlConfigurator(Watch = true)]

having done do we can now run a first unit test that accesses the database via NHibernate. The output generated by Log4Net in the unit test runner is similar to this

2008-07-02 08:40:07,249 INFO NHibernate 2.0.0.1001 (2.0.0.1001)

2008-07-02 08:40:07,251 INFO hibernate-configuration section not found in application configuration file

2008-07-02 08:40:07,254 INFO Bytecode provider name : lcg

2008-07-02 08:40:07,257 INFO Using reflection optimizer

2008-07-02 08:40:08,515 DEBUG connection.provider=NHibernate.Connection.DriverConnectionProvider

2008-07-02 08:40:08,516 DEBUG dialect=NHibernate.Dialect.MsSql2005Dialect

2008-07-02 08:40:08,517 DEBUG connection.driver_class=NHibernate.Driver.SqlClientDriver

2008-07-02 08:40:08,517 DEBUG connection.connection_string=Server=(local);Database=NHibernateFAQ;Integrated Security=SSPI;

2008-07-02 08:40:08,518 DEBUG show_sql=false

2008-07-02 08:40:08,522 DEBUG properties: System.Collections.Generic.Dictionary`2[System.String,System.String]

2008-07-02 08:40:08,526 INFO Mapping resource: LoggingSample.Person.hbm.xml

2008-07-02 08:40:08,872 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect

2008-07-02 08:40:11,425 INFO Mapping class: LoggingSample.Person -> Person

2008-07-02 08:40:11,537 DEBUG Mapped property: Id -> Id, type: Int32

2008-07-02 08:40:11,612 DEBUG Mapped property: LastName -> LastName, type: String

2008-07-02 08:40:11,614 DEBUG Mapped property: FirstName -> FirstName, type: String

2008-07-02 08:40:11,614 DEBUG Mapped property: Birthdate -> Birthdate, type: DateTime

2008-07-02 08:40:11,632 INFO checking mappings queue

2008-07-02 08:40:11,634 INFO processing one-to-many association mappings

2008-07-02 08:40:11,634 INFO processing one-to-one association property references

2008-07-02 08:40:11,634 INFO processing foreign key constraints

2008-07-02 08:40:11,712 INFO Using dialect: NHibernate.Dialect.MsSql2005Dialect

2008-07-02 08:40:11,716 INFO Using dialect defined converter

...

2008-07-02 08:40:12,410 DEBUG Static SQL for entity: LoggingSample.Person

2008-07-02 08:40:12,411 DEBUG Version select: SELECT Id FROM Person WHERE Id = ?

2008-07-02 08:40:12,412 DEBUG Snapshot select: SELECT person_.Id, person_.LastName as LastName0_, person_.FirstName as FirstName0_, person_.Birthdate as Birthdate0_ FROM Person person_ WHERE person_.Id=?

...

as you can see LOADS of information.

To tune the generated logging information a little bit we can filter the output generated by NHibernate by putting the following configuration section into our config file (put them just after the root section inside the log4net node)

<logger name="NHibernate" additivity="false">

<level value="WARN"/>

<appender-ref ref="RollingFile" />

<appender-ref ref="ConsoleAppender" />

</logger>

<logger name="NHibernate.SQL" additivity="false">

<level value="ALL"/>

<appender-ref ref="RollingFile" />

<appender-ref ref="ConsoleAppender" />

</logger>

Obviously NHibernate defines two different loggers NHibernate and NHibernate.SQL. The first one receives all logging output that NHibernate generates where as the second one only receives the sql statements generated by NHibernate.

With the above settings in place the output generated is reduced to

2008-07-02 08:48:58,636 DEBUG select person0_.Id as Id0_,

                        person0_.LastName as LastName0_,

                        person0_.FirstName as FirstName0_,

                        person0_.Birthdate as Birthdate0_

                        from Person person0_

That's what we want. Only if we have some weird problems we need to change the priority level of the NHibernate filter to say INFO or DEBUG.

As usual you can find a demo solution here.

Get unique results from joined queries

John Davidson — Thu, 08 Sep 2011 00:31:52 GMT
Current revision posted to How to by John Davidson on 07/09/2011 09:31:52 p.m.

Get unique results from joined queries

Filed under: query

Problem:

A recurring issue that new NHibernate users keep asking about, is the fact that they sometimes get duplicate results from their queries

For example, take a look at the next model:

where Comment.Name refer to the name of the person who wrote the comment.

If you'd want to issue a query on Post that joins to Comment, say "all of the posts that were commented by 'Ken Egozi'", the next hql query should do the trick:

select p from Post p join p.Comments c where c.Name = 'Ken Egozi'";

So, you go ahead and

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .List<post>();

Assuming the next data is in the DB:

Post#1
Comment by 'Ken Egozi' Comment by 'Fabio Maulo' Comment by 'Ken Egozi' Post#2 Comment by 'Fabio Maulo' Post#3 Comment by 'Fabio Maulo' Comment by 'Ken Egozi'

you'd expect the list 'posts' to include two posts: Post#1 and Post#3.
However, if you'd look into posts, you'll see that it has three entries, two entries pointing to Post#1 and one entry pointing to Post#3Buy Term Paper AND Buy Research Paper

Note that NHibernate is smart enough not to create two separate instances for Post#1, but rather a single instance will be created, and the two entries in the list will point to the same instance in memory.Buy Thesis AND Buy Dissertation AND Buy Essay

Explanation:

The said hql query (or an equivalent Criteria) is translated to the joined SELECT clause

SELECT {p.*} FROM Posts p JOIN Comments c ON c.PostId = p.Id WHERE c.[Name] = 'Ken Egozi'

where {p.*} is substituted by the list of fields needed to satisfy a Post object. Running this SQL query directly on the data detailed above, will result with three lines in the resultset.

Solutions

There are three solutions to that in SQL world:

The DISTINCT keyword, when added on the fields of Posts, will ensure that there will be no duplicate lines. there are a few problems with that. Some RDBMS systems will not allow DISTINCT over certain data types, like the blob types in SQL Server. And if you also need to retrieve the joined data, then the DISTINCT keyword will be useless.

Using a subselect

SELECT * FROM Posts p WHERE EXISTS ( SELECT 1 FROM Comments c WHERE c.PostId = p.Id AND c.[Name] = 'Ken Egozi' )

Remove duplicates in the client code.

The solutions in NHibernate's world, in accordance to the SQL solutions:

Use the 'distinct' keyword.
The problems that exists in the SQL world still apply, and it can only be used in HQL, not it Criteria API.

Use subselects.
The syntax in HQL:

from Post p where exists ( from Comment c where c.Post = p and c.Name = 'Ken Egozi' )

and in Criteria API:

var commentsByKenEgozi = DetachedCriteria.For<comment>() .Add(Restrictions.Eq("Name", "Ken Egozi")) .Add(Restrictions.EqProperty("Post.Id", "p.Id")) .SetProjection(NHibernate.Criterion.Projections.Id()); var posts = session.CreateCriteria(typeof (Post), "p") .Add(Subqueries.Exists(commentsByKenEgozi)) .List<post>();</comment>

Remove duplicates in client code.
That's actually pretty easy with NHibernate, thanks to the result transformers. all you need to do is add .SetResultTransformer(new DistinctRootEntityResultTransformer()) to either your query, or criteria, and NHibernate will remove duplicate entries from the resulted list.
so, using the same hql as in the first example, you can write

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .SetResultTransformer(new DistinctRootEntityResultTransformer()) .List<post>();

Get unique results from joined queries

markweee — Wed, 30 Mar 2011 11:28:01 GMT
Revision 5 posted to How to by markweee on 30/03/2011 08:28:01 a.m.

Get unique results from joined queries

Filed under: query

Problem:

A recurring issue that new NHibernate users keep asking about, is the fact that they sometimes get duplicate results from their queries

For example, take a look at the next model:

where Comment.Name refer to the name of the person who wrote the comment.

If you'd want to issue a query on Post that joins to Comment, say "all of the posts that were commented by 'Ken Egozi'", the next hql query should do the trick:

select p from Post p join p.Comments c where c.Name = 'Ken Egozi'";

So, you go ahead and

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .List<post>();

Assuming the next data is in the DB:

Post#1
Comment by 'Ken Egozi' Comment by 'Fabio Maulo' Comment by 'Ken Egozi' Post#2 Comment by 'Fabio Maulo' Post#3 Comment by 'Fabio Maulo' Comment by 'Ken Egozi'

you'd expect the list 'posts' to include two posts: Post#1 and Post#3.
However, if you'd look into posts, you'll see that it has three entries, two entries pointing to Post#1 and one entry pointing to Post#3 Buy Term Paper AND Buy Research Paper

Note that NHibernate is smart enough not to create two separate instances for Post#1, but rather a single instance will be created, and the two entries in the list will point to the same instance in memory. Buy Thesis AND Buy Dissertation AND Buy Essay

Explanation:

The said hql query (or an equivalent Criteria) is translated to the joined SELECT clause

SELECT {p.*} FROM Posts p JOIN Comments c ON c.PostId = p.Id WHERE c.[Name] = 'Ken Egozi'

where {p.*} is substituted by the list of fields needed to satisfy a Post object. Running this SQL query directly on the data detailed above, will result with three lines in the resultset.

Solutions

There are three solutions to that in SQL world:

The DISTINCT keyword, when added on the fields of Posts, will ensure that there will be no duplicate lines. there are a few problems with that. Some RDBMS systems will not allow DISTINCT over certain data types, like the blob types in SQL Server. And if you also need to retrieve the joined data, then the DISTINCT keyword will be useless.

Using a subselect

SELECT * FROM Posts p WHERE EXISTS ( SELECT 1 FROM Comments c WHERE c.PostId = p.Id AND c.[Name] = 'Ken Egozi' )

Remove duplicates in the client code.

The solutions in NHibernate's world, in accordance to the SQL solutions:

Use the 'distinct' keyword.
The problems that exists in the SQL world still apply, and it can only be used in HQL, not it Criteria API.

Use subselects.
The syntax in HQL:

from Post p where exists ( from Comment c where c.Post = p and c.Name = 'Ken Egozi' )

and in Criteria API:

var commentsByKenEgozi = DetachedCriteria.For<comment>() .Add(Restrictions.Eq("Name", "Ken Egozi")) .Add(Restrictions.EqProperty("Post.Id", "p.Id")) .SetProjection(NHibernate.Criterion.Projections.Id()); var posts = session.CreateCriteria(typeof (Post), "p") .Add(Subqueries.Exists(commentsByKenEgozi)) .List<post>();</comment>

Remove duplicates in client code.
That's actually pretty easy with NHibernate, thanks to the result transformers. all you need to do is add .SetResultTransformer(new DistinctRootEntityResultTransformer()) to either your query, or criteria, and NHibernate will remove duplicate entries from the resulted list.
so, using the same hql as in the first example, you can write

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .SetResultTransformer(new DistinctRootEntityResultTransformer()) .List<post>();

Get unique results from joined queries

Woil — Thu, 18 Sep 2008 16:10:22 GMT
Revision 4 posted to How to by Woil on 18/09/2008 01:10:22 p.m.

Get unique results from joined queries

Filed under: query

Problem:

A recurring issue that new NHibernate users keep asking about, is the fact that they sometimes get duplicate results from their queries

For example, take a look at the next model:

where Commment.Name Comment.Name refer to the name of the person who wrote the comment.

If you'd want to issue a query on Post that joins to Comment, say "all of the posts that were commented by 'Ken Egozi'", the next hql query should do the trick:

select p from Post p join p.Comments c where c.Name = 'Ken Egozi'";

So, you go ahead and

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .List<post>();

Assuming the next data is in the DB:

Post#1
Comment by 'Ken Egozi' Comment by 'Fabio Maulo' Comment by 'Ken Egozi' Post#2 Comment by 'Fabio Maulo' Post#3 Comment by 'Fabio Maulo' Comment by 'Ken Egozi'

you'd expect the list 'posts' to include two posts: Post#1 and Post#3.
However, if you'd look into posts, you'll see that it has three entries, two entries pointing to Post#1 and one entry pointing to Post#3

Note that NHibernate is smart enough not to create two separate instances for Post#1, but rather a single instance will be created, and the two entries in the list will point to the same instance in memory.

Explanation:

The said hql query (or an equivalent Criteria) is translated to the joined SELECT clause

SELECT {p.*} FROM Posts p JOIN Comments c ON c.PostId = p.Id WHERE c.[Name] = 'Ken Egozi'

where {p.*} is substituted by the list of fields needed to satisfy a Post object. Running this SQL query directly on the data detailed above, will result with three lines in the resultset.

Solutions

There are three solutions to that in SQL world:

The DISTINCT keyword, when added on the fields of Posts, will ensure that there will be no duplicate lines. there are a few problems with that. Some RDBMS systems will not allow DISTINCT over certain data types, like the blob types in SQL Server. And if you also need to retrieve the joined data, then the DISTINCT keyword will be useless.

Using a subselect

SELECT * FROM Posts p WHERE EXISTS ( SELECT 1 FROM Comments c WHERE c.PostId = p.Id AND c.[Name] = 'Ken Egozi' )

Remove duplicates in the client code.

The solutions in NHibernate's world, in accordance to the SQL solutions:

Use the 'distinct' keyword.
The problems that exists in the SQL world still apply, and it can only be used in HQL, not it Criteria API.

Use subselects.
The syntax in HQL:

from Post p where exists ( from Comment c where c.Post = p and c.Name = 'Ken Egozi' )

and in Criteria API:

var commentsByKenEgozi = DetachedCriteria.For<comment>() .Add(Restrictions.Eq("Name", "Ken Egozi")) .Add(Restrictions.EqProperty("Post.Id", "p.Id")) .SetProjection(NHibernate.Criterion.Projections.Id()); var posts = session.CreateCriteria(typeof (Post), "p") .Add(Subqueries.Exists(commentsByKenEgozi)) .List<post>();</comment>

Remove duplicates in client code.
That's actually pretty easy with NHibernate, thanks to the result transformers. all you need to do is add .SetResultTransformer(new DistinctRootEntityResultTransformer()) to either your query, or criteria, and NHibernate will remove duplicate entries from the resulted list.
so, using the same hql as in the first example, you can write

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .SetResultTransformer(new DistinctRootEntityResultTransformer()) .List<post>();

Get unique results from joined queries

Ken Egozi — Fri, 12 Sep 2008 14:43:10 GMT
Revision 3 posted to How to by Ken Egozi on 12/09/2008 11:43:10 a.m.

Get unique results from joined queries

Problem:

A recurring issue that new NHibernate users keep asking about, is the fact that they sometimes get duplicate results from their queries

For example, take a look at the next model:

where Commment.Name refer to the name of the person who wrote the comment.

If you'd want to issue a query on Post that joins to Comment, say "all of the posts that were commented by 'Ken Egozi'", the next hql query should do the trick:

select p from Post p join p.Comments c where c.Name = 'Ken Egozi'";

So, you go ahead and

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .List<post>();

Assuming the next data is in the DB:

Post#1
Comment by 'Ken Egozi' Comment by 'Fabio Maulo' Comment by 'Ken Egozi' Post#2 Comment by 'Fabio Maulo' Post#3 Comment by 'Fabio Maulo' Comment by 'Ken Egozi'

you'd expect the list 'posts' to include two posts: Post#1 and Post#3.
However, if you'd look into posts, you'll see that it has three entries, two entries pointing to Post#1 and one entry pointing to Post#3

Note that NHibernate is smart enough not to create two separate instances for Post#1, but rather a single instance will be created, and the two entries in the list will point to the same instance in memory.

Explanation:

The said hql query (or an equivalent Criteria) is translated to the joined SELECT clause

SELECT {p.*} FROM Posts p JOIN Comments c ON c.PostId = p.Id WHERE c.[Name] = 'Ken Egozi'

where {p.*} is substituted by the list of fields needed to satisfy a Post object. Running this SQL query directly on the data detailed above, will result with three lines in the resultset.

Solutions

There are three solutions to that in SQL world:

The DISTINCT keyword, when added on the fields of Posts, will ensure that there will be no duplicate lines. there are a few problems with that. Some RDBMS systems will not allow DISTINCT over certain data types, like the blob types in SQL Server. And if you also need to retrieve the joined data, then the DISTINCT keyword will be useless.

Using a subselect

SELECT * FROM Posts p WHERE EXISTS ( SELECT 1 FROM Comments c WHERE c.PostId = p.Id AND c.[Name] = 'Ken Egozi' )

Remove duplicates in the client code.

The solutions in NHibernate's world, in accordance to the SQL solutions:

Use the 'distinct' keyword.
The problems that exists in the SQL world still apply, and it can only be used in HQL, not it Criteria API.

Use subselects.
The syntax in HQL:

from Post p where exists ( from Comment c where c.Post = p and c.Name = 'Ken Egozi' )

and in Criteria API:

var commentsByKenEgozi = DetachedCriteria.For<comment>() .Add(Restrictions.Eq("Name", "Ken Egozi")) .Add(Restrictions.EqProperty("Post.Id", "p.Id")) .SetProjection(NHibernate.Criterion.Projections.Id()); var posts = session.CreateCriteria(typeof (Post), "p") .Add(Subqueries.Exists(commentsByKenEgozi)) .List<post>();</comment>

Remove duplicates in client code.
That's actually pretty easy with NHibernate, thanks to the result transformers. all you need to do is add .SetResultTransformer(new DistinctRootEntityResultTransformer()) to either your query, or criteria, and NHibernate will remove duplicate entries from the resulted list.
so, using the same hql as in the first example, you can write

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .SetResultTransformer(new DistinctRootEntityResultTransformer()) .List<post>();

Get unique results from joined queries

Fabio Maulo — Fri, 12 Sep 2008 14:34:49 GMT
Revision 2 posted to How to by Fabio Maulo on 12/09/2008 11:34:49 a.m.

Get unique results from joined queries

Problem:

A recurring issue that new NHibernate users keep asking about, is the fact that they sometimes get duplicate results from their queries

For example, take a look at the next model:

where Commment.Name refer to the name of the person who wrote the comment.

If you'd want to issue a query on Post that joins to Comment, say "all of the posts that were commented by 'Ken Egozi'", the next hql query should do the trick:

select p from Post p join p.Comments c where c.Name = 'Ken Egozi'";

So, you go ahead and

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; "; var posts = session.CreateQuery(hql) .List<post>();

Assuming the next data is in the DB:
Post#1
    Comment by 'Ken Egozi'
    Comment by 'Fabio Maulo'
    Comment by 'Ken Egozi'

Post#2
    Comment by 'Fabio Maulo'

Post#3
    Comment by 'Fabio Maulo'
    Comment by 'Ken Egozi'

you'd expect the list 'posts' to include two posts: Post#1 and Post#3.

However, if you'd look into posts, you'll see that it has three entries, two entries pointing to Post#1 and one entry pointing to Post#3

Note that NHibernate is smart enough not to create two separate instances for Post#1, but rather a single instance will be created, and the two entries in the list will point to the same instance in memory.

Explanation:

The said hql query (or an equivalent Criteria) is translated to the joined SELECT clause

SELECT {p.*} FROM Posts p JOIN Comments c ON c.PostId = p.Id WHERE c.[Name] = 'Ken Egozi'

where {p.*} is substituted by the list of fields needed to satisfy a Post object. Running this SQL query directly on the data detailed above, will result with three lines in the resultset.

Solutions

There are three solutions to that in SQL world:

The DISTINCT keyword, when added on the fields of Posts, will ensure that there will be no duplicate lines. there are a few problems with that. Some RDBMS systems will not allow DISTINCT over certain data types, like the blob types in SQL Server. And if you also need to retrieve the joined data, then the DISTINCT keyword will be useless.

Using a subselect

SELECT * FROM Posts p WHERE EXISTS ( SELECT 1 FROM Comments c WHERE c.PostId = p.Id AND c.[Name] = 'Ken Egozi' )

Remove duplicates in the client code.

The solutions in NHibernate's world, in accordance to the SQL solutions:

Use the 'distinct' keyword.
The problems that exists in the SQL world still apply, and it can only be used in HQL, not it Criteria API.

Use subselects.
The syntax in HQL:

from Post p where exists ( from Comment c where c.Post = p and c.Name = 'Ken Egozi' )

and in Criteria API:

var commentsByKenEgozi = DetachedCriteria.For<comment>() .Add(Restrictions.Eq("Name", "Name", "Ken Egozi")) ")) .Add(Restrictions.EqProperty("Post.Id", "p.Id")) "Post.Id", "p.Id")) .SetProjection(NHibernate.Criterion.Projections.Id()); var posts = session.CreateCriteria(typeof session.CreateCriteria(typeof (Post), "p") "p") .Add(Subqueries.Exists(commentsByKenEgozi)) .List<post>();</comment>

Remove duplicates in client code.
That's actually pretty easy with NHibernate, thanks to the result transformers. all you need to do is add .SetResultTransformer(new DistinctRootEntityResultTransformer()) to either your query, or criteria, and NHibernate will remove duplicate entries from the resulted list.
so, using the same hql as in the first example, you can write

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; "; var posts = session.CreateQuery(hql) .SetResultTransformer(new SetResultTransformer(new DistinctRootEntityResultTransformer()) .List<post>();

Get unique results from joined queries

Ken Egozi — Fri, 12 Sep 2008 07:32:51 GMT
Revision 1 posted to How to by Ken Egozi on 12/09/2008 04:32:51 a.m.

Problem:

A recurring issue that new NHibernate users keep asking about, is the fact that they sometimes get duplicate results from their queries

For example, take a look at the next model:

where Commment.Name refer to the name of the person who wrote the comment.

If you'd want to issue a query on Post that joins to Comment, say "all of the posts that were commented by 'Ken Egozi'", the next hql query should do the trick:

select p from Post p join p.Comments c where c.Name = 'Ken Egozi'";

So, you go ahead and

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .List<post>();

Assuming the next data is in the DB:
  Post#1
    Comment by 'Ken Egozi'
    Comment by 'Fabio Maulo'
    Comment by 'Ken Egozi'

  Post#2
    Comment by 'Fabio Maulo'

  Post#3
    Comment by 'Fabio Maulo'
    Comment by 'Ken Egozi'

you'd expect the list 'posts' to include two posts: Post#1 and Post#3.

However, if you'd look into posts, you'll see that it has three entries, two entries pointing to Post#1 and one entry pointing to Post#3

Note that NHibernate is smart enough not to create two separate instances for Post#1, but rather a single instance will be created, and the two entries in the list will point to the same instance in memory.

Explanation:

The said hql query (or an equivalent Criteria) is translated to the joined SELECT clause

SELECT {p.*} FROM Posts p JOIN Comments c ON c.PostId = p.Id WHERE c.[Name] = 'Ken Egozi'

where {p.*} is substituted by the list of fields needed to satisfy a Post object. Running this SQL query directly on the data detailed above, will result with three lines in the resultset.

Solutions

There are three solutions to that in SQL world:

The DISTINCT keyword, when added on the fields of Posts, will ensure that there will be no duplicate lines. there are a few problems with that. Some RDBMS systems will not allow DISTINCT over certain data types, like the blob types in SQL Server. And if you also need to retrieve the joined data, then the DISTINCT keyword will be useless.

Using a subselect
SELECT * FROM Posts p WHERE EXISTS ( SELECT 1 FROM Comments c WHERE c.PostId = p.Id AND c.[Name] = 'Ken Egozi' )

Remove duplicates in the client code.

The solutions in NHibernate's world, in accordance to the SQL solutions:

Use the 'distinct' keyword.
The problems that exists in the SQL world still apply, and it can only be used in HQL, not it Criteria API.

Use subselects.
The syntax in HQL:

from Post p where exists ( from Comment c where c.Post = p and c.Name = 'Ken Egozi' )
and in Criteria API:

var commentsByKenEgozi = DetachedCriteria.For<comment>() .Add(Restrictions.Eq("Name", "Ken Egozi")) .Add(Restrictions.EqProperty("Post.Id", "p.Id")) .SetProjection(NHibernate.Criterion.Projections.Id()); var posts = session.CreateCriteria(typeof (Post), "p") .Add(Subqueries.Exists(commentsByKenEgozi)) .List<post>();</comment>

Remove duplicates in client code.
That's actually pretty easy with NHibernate, thanks to the result transformers. all you need to do is add .SetResultTransformer(new DistinctRootEntityResultTransformer()) to either your query, or criteria, and NHibernate will remove duplicate entries from the resulted list.
so, using the same hql as in the first example, you can write

var hql = @" select p from Post p join p.Comments c where c.Name = 'Ken Egozi'"; var posts = session.CreateQuery(hql) .SetResultTransformer(new DistinctRootEntityResultTransformer()) .List<post>();

Pre-Generate Lazy Loading Proxies

John Davidson — Thu, 08 Sep 2011 00:18:34 GMT
Current revision posted to How to by John Davidson on 07/09/2011 09:18:34 p.m.

Pre-Generate Lazy Loading Proxies

Filed under: lazy loading

Download the latest binaries for NHibernate ProxyGenerators

Extract the binaries to your "lib" directory relative to your source files

Open a command prompt and navigate the to "bin" directory in your web project.

Enter the following command:
..\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)

Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.

You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Sample Commands

Generate proxies for ActiveRecord
NHPG.exe /g:activerecord /o:Example.ActiceRecordDomain.Proxies.dll Example.ActiveRecordDomain.dll

Generate proxies with multiple class mapping assemblies Research Papers AND Term Papers
NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain1.dll Example.Domain2.dll

Generate proxies with a custom Dialect Essays AND Dissertations AND Theses
NHPG.exe /d:NHibernate.Dialect.Oracle9Dialect /o:Example.Domain.Proxies.dll Example.Domain.dll

Pre-Generate Lazy Loading Proxies

markweee — Wed, 30 Mar 2011 11:30:52 GMT

Revision 12 posted to How to by markweee on 30/03/2011 08:30:52 a.m.

Pre-Generate Lazy Loading Proxies

Filed under: lazy loading

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Sample Commands

Generate proxies for ActiveRecord
NHPG.exe /g:activerecord /o:Example.ActiceRecordDomain.Proxies.dll Example.ActiveRecordDomain.dll
Generate proxies with multiple class mapping assemblies Research Papers AND Term Papers
NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain1.dll Example.Domain2.dll
Generate proxies with a custom Dialect Essays AND Dissertations AND Theses
NHPG.exe /d:NHibernate.Dialect.Oracle9Dialect /o:Example.Domain.Proxies.dll Example.Domain.dll

Pre-Generate Lazy Loading Proxies

Bill Pierce — Wed, 08 Oct 2008 18:03:24 GMT

Revision 11 posted to How to by Bill Pierce on 08/10/2008 03:03:24 p.m.

Pre-Generate Lazy Loading Proxies

Filed under: lazy loading

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Sample Commands

Generate proxies for ActiveRecord
NHPG.exe /g:activerecord /o:Example.ActiceRecordDomain.Proxies.dll Example.ActiveRecordDomain.dll
Generate proxies with multiple class mapping assemblies
NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain1.dll Example.Domain2.dll
Generate proxies with a custom Dialect
NHPG.exe /d:NHibernate.Dialect.Oracle9Dialect /o:Example.Domain.Proxies.dll Example.Domain.dll

Pre-Generate Lazy Loading Proxies

Bill Pierce — Tue, 23 Sep 2008 18:22:57 GMT

Revision 10 posted to How to by Bill Pierce on 23/09/2008 03:22:57 p.m.

Pre-Generate Lazy Loading Proxies

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Sample Commands

Generate proxies for ActiveRecord
NHPG.exe /g:activerecord /o:Example.ActiceRecordDomain.Proxies.dll Example.ActiveRecordDomain.dll
Generate proxies with multiple class mapping assemblies
NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain1.dll Example.Domain2.dll

Pre-Generate Lazy Loading Proxies

Bill Pierce — Tue, 23 Sep 2008 18:11:02 GMT

Revision 9 posted to How to by Bill Pierce on 23/09/2008 03:11:02 p.m.

Pre-Generate Lazy Loading Proxies

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Sample Commands

Pre-Generate Lazy Loading Proxies
- Generate proxies for ActiveRecord
  NHPG.exe /g:activerecord /o:Example.ActiceRecordDomain.Proxies.dll Example.ActiveRecordDomain.dll
- Generate proxies with multiple class mapping assemblies
  NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain1.dll Example.Domain2.dll

Pre-Generate Lazy Loading Proxies

Bill Pierce — Tue, 23 Sep 2008 18:09:19 GMT

Revision 8 posted to How to by Bill Pierce on 23/09/2008 03:09:19 p.m.

Pre-Generate Lazy Loading Proxies

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Sample Commands

Pre-Generate Lazy Loading Proxies for ActiveRecord
NHPG.exe /g:activerecord /o:Example.ActiceRecordDomain.Proxies.dll Example.ActiveRecordDomain.dll

Pre-Generate Lazy Loading Proxies

Bill Pierce — Tue, 23 Sep 2008 03:58:50 GMT

Revision 7 posted to How to by Bill Pierce on 23/09/2008 12:58:50 a.m.

Pre-Generate Lazy Loading Proxies

***This is preliminary documentation***

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\NHPG .\..\..\lib\bin\net-2.0\NHPG.exe /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG

NHPG.exe: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Pre-Generate Lazy Loading Proxies

Bill Pierce — Mon, 22 Sep 2008 17:19:24 GMT

Revision 6 posted to How to by Bill Pierce on 22/09/2008 02:19:24 p.m.

Pre-Generate Lazy Loading Proxies

***This is preliminary documentation***

Download the latest binaries for NHibernate ProxyGenerators
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\NHPG /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.
You're done! Pre-generated lazy loading proxies can be used with NHibernate to Run in Medium Trust

Pre-Generate Lazy Loading Proxies

Bill Pierce — Mon, 22 Sep 2008 17:15:02 GMT

Revision 5 posted to How to by Bill Pierce on 22/09/2008 02:15:02 p.m.

Pre-Generate Lazy Loading Proxies

***This is preliminary documentation***

Download the latest binaries for [howtonh:/media/g/proxygenerators/default.aspx|NHibernate NHibernate ProxyGenerators]
Extract the binaries to your "lib" directory relative to your source files
Open a command prompt and navigate the to "bin" directory in your web project.
Enter the following command:
..\..\..\lib\NHPG /o:Example.Domain.Proxies.dll Example.Domain.dll

NHPG: The console application that generates the proxies. Included in the binary distribution from step 1
/o: The path to the assembly that will be generated by NHPG
Example.Domain.dll: The assembly that contains your NHibernate Mappings (hbm.xml files)
Add 'proxyfactory.factory_class' to your NHibernate configuration file:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=Development;Trusted_Connection=True;</property>
    <mapping assembly="Example.Domain" />

    <property name="proxyfactory.factory_class">CastleStaticProxyFactoryFactory, Example.Domain.Proxies</property>
</session-factory>
</hibernate-configuration>
Replace Example.Domain.Proxies with the name of the assembly used for argument '/o' in Step 4.