search

mfenniak / rethinkdb-net

A C# / .NET client driver for RethinkDB.
Other
247 stars 37 forks source link

Support for Inheritance in documents / embedded documents #238

Open FransBouma opened 9 years ago

FransBouma commented 9 years ago

Hi,

I'm adding support for derived models to LLBLGen Pro (an entity modeling/ORM) and one of the document databases we're supporting is RethinkDB. I'm running into a problem though: the test models we use for the DocDBs contains inheritance (subtypes in embedded docs). As I couldn't find any information about this I assumed RethinkDB would handle this as RavenDB does: it takes care of the type serialization and at deserialization time it uses that type information to deserialize the data in the right type instance (e.g. a subtype or the supertype).

Is there any support for this in RethinkDB? See this gist for an example of what I'm referring at: https://gist.github.com/FransBouma/af3740bb8c09974f6bcd

TIA

FransBouma commented 9 years ago

I updated the post with a new gist, as the original one for mongo didn't contain the doc classes! https://gist.github.com/FransBouma/af3740bb8c09974f6bcd

mfenniak commented 9 years ago

This RethinkDB driver currently doesn't have any support for this. I can certainly see the use-case for this, and it would be nice to have.

What format does RavenDB use to store the type information in the document?

FransBouma commented 9 years ago

RavenDB uses a _t variable with the full type name of the .net type. MongoDB uses a _t variable in the json (so like ravendb) but with the normal type name (so not with the namespace and assembly name) and also stores supertypes. This is then usable to filter on supertypes.

I filed an issue with RethinkDB itself, see: https://github.com/rethinkdb/rethinkdb/issues/4966 (They asked me via twitter to do this, after I mentioned it that I found it surprising that it was missing). No reply yet.

mfenniak commented 9 years ago

Hm... I'm not sure I love the idea of using the full .NET type name. It causes a few practical problems, like, you can't rename, renamespace, or move your type from one assembly to another without either breaking your DB, or having to perform a migration step. It's also architecturally strange in that it couples the platform of your application (.NET) with data in the DB. Anyway, it's a valid option for an implementation, but it might also make sense to provide some flexibility in how the type is determined.

As you mentioned in the RethinkDB issue, this is probably something that is more of a client-side concern. And it's also something that is more of a concern for statically typed languages like .NET and Java... if I was using the Python driver, I'm probably happy getting a dict back from the DB driver, and I don't need type information. It would probably be valuable to use an approach here that is consistent and compatible with other client drivers.

FransBouma commented 9 years ago

The full type name is definitely not something you'd want in that case indeed. MongoDB's C# client has a 'discriminator' feature where you can specify the value that's being stored for a given type (e.g. you can emit a number, or a string, whatever you like). See: http://mongodb.github.io/mongo-csharp-driver/2.0/reference/bson/mapping/polymorphism/

Anyway, if RethinkDB can add this to the core, it would be better, I think.