Problem with derserialization to properties that are an interface

[paulbrower]

I've been googling and experimenting for hours, to no avail.

I'm using the latest Official C# MongoDB Driver.

I can't figure out how to deserialize a bson doc from a collection
where the object being deserialized is an interface.

For simplicity, take the following interface/class:

public interface IFoo
{
public string Description {get;set;}
}

[Serializable]
public class Foo: IFoo
{
public string Description {get;set;}
}

//this won't deserialize, as I get a 'No Serializer found for type
'IFoo'" error message
[Serializable]
public class Bar
{
public IFoo MyFoo {get;set;}
}

//this works fine
[Serializable]
public class Bar
{
public Foo MyFoo {get;set;}
}

Is there some way I can inform mongodb to deserialize IFoo as a
concrete Foo?

[craiggwilson]

Paul, I cannot reproduce your problem.  You may have simplified it, but using the above information, everything works as expected.  (I did need to add an identifier to the Bar class).  You can see the code I used here:  http://pastebin.com/68Ddzh7t

[Paul Brower]

Thanks.  I was able to also reproduce the sample I provided with no errors.  I then started digging some more, and found the deserialization error was getting throws because objects in my collection were originally created when the class did NOT use interfaces.  As a result, the “_t” was not in the bson doc.

 

Here is a snippet of a the bson doc that gets created after modifying my c# class to use interfaces  (Notice the ** “_t”:”Location” **).  I really wish (is there??) there were a way to tell mongo that certain ‘properties’ in a bson document should be deserialized out to a specify type.  Otherwise, I have to re-create all my documents in the collection.  Any thoughts on that?

 

{

  "_id" : ObjectId("4fad3b57b71e9a2bb038e069"),

  "Status" : "A",

  "ClassCodeObjId" : ObjectId("4fad3343b71e9a2bb038d73c"),

  "AnimalId" : "2370000028375",

  "SpeciesId" : "Swine",

  "CompanyId" : "Newsham",

  "BloodLineId" : "PTRN",

  "BirthDt" : new Date("9/19/2009 19:00:00"),

  "Gender" : "F",

  "SireCompanyId" : "Newsham",

  "SireBloodLineId" : "PTRN",

  "SireLineId" : "EBX",

  "SireAnimalID" : "2360000017205",

  "DamCompanyId" : "Newsham",

  "DamBloodLineId" : "PTRN",

  "DamLineId" : "EBX",

  "DamAnimalID" : "2370000018407",

  "CurrentLocation" : {

    "_t" : "Location",

    "_id" : ObjectId("4fad3378b71e9a2bb038e003"),

    "CompanyId" : "Newsham",

    "FarmID" : "25037",

    "IsActive" : true

  },

  "AddDt" : new Date("5/11/2012 11:16:23"),

  "AddBy" : "pbrower",

  "ModDt" : new Date("5/11/2012 11:16:23"),

  "ModBy" : "pbrower"

}

 

 

Paul Brower | Director of Information Technology
Newsham Choice Genetics

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/Vsio0I82paQJ.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[craiggwilson]

There are a couple of solutions to your problem, but the simplest one is this:  Fix the data.  MongoDB isn't different than any other database in that when you change your entity models (different types, changing property names, etc...) you may need to run an update script to get your data into a form that can be understood again.  In this case, I'd run an update script that inserts the "_t" field into all the documents that don't already have it.  You can do this using the $set operator.  If you only have a single implementation of your interfaces, then this will be easy enough. If you have multiple implementations, you'll obviously need to make sure you use the correct discriminator value.

If this is something you can't or don't want to do, I can walk you through a couple of other solutions.

To unsubscribe from this group, send email to mongodb-user+unsubscribe@googlegroups.com.

[Paul Brower]

Can the descriminators be set via attributes in the interface or class so that the “_t” doesn’t have to exist in the bson doc?

 

Paul Brower | Director of Information Technology
Newsham Choice Genetics

 

To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

--

You received this message because you are subscribed to the Google Groups "mongodb-user" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/tL8pjOt90cMJ.

To post to this group, send email to mongod...@googlegroups.com.

To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.

[craiggwilson]

Currently, no.  If you would like this feature, you can file a request in jira at jira.mongodb.org.    In the meantime, you can write a custom discriminator convention for your IFoo type such that it will use a default if it doesn't find a discriminator.  You can see that code here:  http://pastebin.com/9UweEKBe

HOWEVER: I would still highly suggest you simply fix your data.  It will make things simpler in the long term regarding maintenance and development.

To unsubscribe from this group, send email to mongodb-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/tL8pjOt90cMJ.
To post to this group, send email to mongod...@googlegroups.com.

To unsubscribe from this group, send email to mongodb-user+unsubscribe@googlegroups.com.