views:

227

answers:

2

I'm implementing generic, persistent .NET collections based on top of the ESENT database engine (using the ManagedEsent interop layer). So far I have been focusing on classes that exactly mimic their System.Collections.Generic counterparts, except that they take a path in the constructor indicating where the database should go. Code like this is working:

using Microsoft.Isam.Esent.Collections.Generic;

static void Main(string[] args)
{
    var dictionary = new PersistentDictionary<string, string>("Names");
    Console.WriteLine("What is your first name?");
    string firstName = Console.ReadLine();
    if (dictionary.ContainsKey(firstName))
    {
     Console.WriteLine("Welcome back {0} {1}", firstName, dictionary[firstName]);
    }
    else
    {
     Console.WriteLine("I don't know you, {0}. What is your last name?", firstName);
     dictionary[firstName] = Console.ReadLine();
    }
}

My questions are:

  • Other than compatability with Stack, Queue and Dictionary what features do people want/need in persisted collections?
  • Should I require version 2.0 or version 3.5 of the .NET framework?
  • The key and value types are both restricted to the basic .NET types (bool, byte, [all the integers], float, double, Guid, DateTime and string). I might add support for values which are serializable structures. Is this type restriction too painful?
  • What kind of performance benchmarks do people want to see?
  • What kind of applications do people want to use a PersistedDictionary for?

I will have the first release ready next week, but I want to make sure I'm building the right thing.

+1  A: 

Type restriction may be acceptable on keys, but on values, I'd expect anything that's [Serializable] to work. Otherwise, what's the point? Simple cases like Dictionary<int, string> is seen in textbooks much more often than in real world.

Pavel Minaev
The problem is that I can't match the system dictionary semantics. If you add a serializable object to a dictionary it is added by reference, so changing the object changes the object in the dictionary (they are the same object). Any object added to a PersistentDictionary will be added by value, creating a clone.I'm worried about the API weirdness this would generate.
Laurion Burchall
For "basic" types, semantics will still match. For user-defined types, it will still match for value types and pseudo-value reference types (i.e. immutable classes such as `Uri`). Even where it won't match, I would argue that such behavior is still much more useful than forbidding it outright. There is some potential for confusion there, of course, so you will have to clearly warn about this. But I think that usefulness trumps simplicity here.
Pavel Minaev
+2  A: 

I've published the PersistentDictionary on Codeplex. This only supports serializing structures, but I will work on a different data structure that supports storing and retrieving arbitrary objects.

http://managedesent.codeplex.com/