Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 10 | Comments: 37

filter by tags archive

NHibernate Tidbit – using <set/> without referencing Iesi.Collections

time to read 1 min | 117 words

Some people don’t like having to reference Iesi.Collections in order to use NHibernate <set/> mapping. With NHibernate 2.1, this is possible, since we finally have a set type in the actual BCL. We still don’t have an ISet<T> interface, unfortunately, but that is all right, we can get by with ICollection<T>.

In other words, any ISet<T> association that you have can be replaced with an ICollection<T> and instead of initializing it with Iesi.Collections.Generic.HashedSet<T>, you can initialize it with System.Collections.Generic.HashSet<T>.

Note that you still need to deploy Iesi.Collections with your NHibernate application, but that is all, you can remove the association to Iesi.Collections and use only BCL types in your domain model, with not external references.


Comments

Darren Thomas

I'm learning nHibernate so this is probably something I've done. When I replaced ISet with ICollection I noticed that I get an extra update after the insert statement when saving? If I replace ICollection with ISet the behaviour is as expected, a single insert statement.

What could be doing this?

Ayende Rahien

Darren,

Please post everything (mapping, code & SQL) to the nh users mailing list

Darren Thomas

Good point :) this isn't a support forum

Thanks

cowgaR

So in other words .NET 3.5 introduces HashSet <t but we still need to wait for the interface (.net 4.0 maybe) so we have an ICollection workaround.

Question is, why this works only with NH 2.1 (alpha currently)? Because of .NET 2.0 limitation of current NHibernate?

thanks

Ayende Rahien

No,

because previous version had an explicit check which I removed

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. Production postmortem: The case of the memory eater and high load - 2 hours from now
  2. Production postmortem: The case of the lying configuration file - about one day from now
  3. Production postmortem: The industry at large - 2 days from now
  4. The insidious cost of allocations - 3 days from now
  5. Find the bug: The concurrent memory buster - 4 days from now

And 4 more posts are pending...

There are posts all the way to Sep 10, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    14 Aug 2015 - The case of the man in the middle
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats