> Would it be possible to add some override points in the driver to do Linq
> query transformation as well as some processing done on an object after its
> deserialized but before its returned from the enumerator?  Here is what we
> are trying to accomplish, we have some fields where we've "compressed" some
> strings to save space in the database.  Basically we've taken a string,
> stuck it in a lookup table to get back an int Id and the int gets stored in
> the database.  We would like to put that as close to the database as
> possible to make it more automatic and not require the developer to think
> about it too much.  The object is modeled like this:

> class Foo {
>     [BsonIgnore]
>     [MyCompressedField("BarId")]
>     public string BarString { get; set; }

>     [BsonElement("B")]
>     public int BarId { get; set; }
> }

> So we want to do a few things here:
> 1. Rewrite Linq queries so that when someone does FooCollection.Where(f =>
> f.BarString == "bar"), that is translated to FooCollection.Where(f =>
> f.BarId == 123) which results in the mongo query: "{ B : 123 }". where 123
> is the key for the string "bar".
> 2. As the object comes out of the database repopulate our string field:
>    f => { f.BarString = stringLookup.GetString(f.BarId) }
> 3. Inserts/Updates need to do the reverse:
>    f=> { f.BarId = stringLookup.GetStringId(f.BarString) }

> We have 1 and 2 working, but we've had to wrap the MongoQueryProvider and
> MongoQueryable in odd ways.  The BeginInit/EndInit methods don't really
> work for this scenario as we require a reference to external object to do
> the conversion, and it is not a singleton.

> So could something like this be added so that we have some places to
> register some callbacks to occur?  I would be willing to write the code if
> I could get some pointers as to where the best places to put these would
> be.  I think Item #1 seems like it would go on MongoCollection.  

> Thanks,
> Ted