db4o Developer Community

db4o open source object database, native to Java and .NET
Welcome to db4o Developer Community Sign in | Join
in Search
More Search Options

Product News from the Core Team

This blog features product news right from the core developer team, once new features and functions get checked into Subversion, available as Continuous Build every 2 hours.

Collected Generics, Volume 1

Finally we are starting to harvest the fruits of our work on pluggable type handlers. As a first step, please welcome .NET generic collections to the exclusive club of types natively supported by db4o in the upcoming 7.6 build.

In principle, .NET generic collections could already be persisted in previous versions, but there was no dedicated handling in place for them. db4o would not recognize them as collections and would simply handle them as any other object - inspect their internal layout and persist the field values found. This approach came with some pitfalls. Most notably, db4o would not recognize the collection's internal state objects as parts of a single, atomic unit - in C/S mode, concurrent updates from multiple clients against the same collections could have resulted in inconsistent internal collection state in the worst case. Furthermore, issues could arise with specific collection implementations: Dictionaries, for example, would persist hash codes alongside keys/values and could stumble when attempting to reload this data in a different runtime version (as GetHashCode() implementations may change yielding different hash values). Plus, last but not least, dedicated collection handling opens the path for performance optimizations.

With the current type handler infrastructure in place, providing custom handling for .NET generic collections as its first "real world" application went pretty smooth - actually the bulk of the effort was spent on the implementation of combinatorial regression testing of permutations of collection, field and element types - take a look at GenericCollectionTypeHandlerTestSuite, if you're interested. As of now, dedicated type handler support is available for the following collection flavors:

  • List<T>
  • LinkedList<T>
  • Stack<T>
  • Queue<T>
  • Dictionary<K,V>
  • SortedList<K,V>
  • SortedDictionary<K,V>

These collections now should blend in seamlessly with the behavior of non-generic collections. More to come - but if you're missing a dedicated type handler for a specific flavor, of course you're also invited to contribute. ;)
Published Friday, September 12, 2008 8:49 PM by Patrick Roemer

Comments

 

Andrei.hu said:

Cool. I think it's quite a big boost to the applicability of db4o.

September 25, 2008 9:17 AM
 

Marek Istvanek said:

There should be also ISerializable type handler, because those are types which need special storing.

Eg. Uri, Dictionary<>, ...

What would be a type handler precedence when more than one type handler is installed for a class like Dictionary?

September 26, 2008 7:14 AM
 

emperon said:

Since the actual implementations of these collections can vary between mono and .net how are you going to ensure the compatibility and portability ?

September 30, 2008 6:20 PM
 

Rodrigo B. de Oliveira said:

By working against their public interfaces, emperon.

September 30, 2008 7:23 PM
 

emperon said:

Rodrigo I don't see any interfaces in above collections

October 3, 2008 6:47 PM
 

Rodrigo B. de Oliveira said:

emperon: IDictionary<TKey, TValue>, IList<T> and ICollection<T>.

October 3, 2008 7:18 PM
 

emperon said:

Hello Rodrigo, may be I should be explicit. Now with those additions to 7.6 can I still work safely without breaking mono compability ? Develop on windows and port to linux or vice versa ?

Don't take me offensive, I am a big fan of you and Boo :)

October 4, 2008 9:21 AM
Anonymous comments are disabled

This Blog

Syndication RSS Feeds

News

Get the latest features every 2 hours with the Continuous Build!