8

I have done a little bit of work with mongoDB in C# but all of my code is still in development. I am wondering what useful patterns people have found in evolving their domain classes over time as new properties are created, altered and removed. I am clear that I will need to either run updates on all my stored data or make sure my domain classes know how to deal with the older format records, but over time I could imagine this becoming chaotic if a class has know how to deal with all possible form formats.

Am I over thinking this? Is this mostly just a case of using good defensive programming?

Matthew Nichols
  • 4,866
  • 4
  • 41
  • 48
  • Fairly new subject, good question.. but probably belongs on programmers.stackexchange.com because it's more conceptual in nature versus a normal "problem" to solve. – NotMe Mar 06 '12 at 23:28

1 Answers1

2
  1. Adding new properties to your data objects can’t be easier. You just add them. Unless you worry about these properties being null for object which exist in the database, you don’t have to do anything else. If some users/machines use the older version of your application and your classes were marked with BsonIgnoreExtraElementsAttribute, they may not even need to update their software.
  2. Removing obsolete properties can’t be easier. You just remove them in your classes. If your classes are marked with BsonIgnoreExtraElementsAttribute, then you don’t even have to remove them in your database (in case, for example, your users have several versions of your app).
  3. Renaming class properties is also easy. The BsonElementAttribute constructor has a parameter, so you can map it to the correct property name in the database.
  4. Changing property type may require you to run an update on your data. But seriously, how often do you change property type from string to int in production?

So in many cases you won't even need to run updates on your data (unless, you change data type or your property affects index). Another point is that adding the BsonIgnoreExtraElementsAttribute is often a good practice, particularly if you are worried about properties being added and/or removed frequently. Following this practice, you can to provide older and newer versions of your application to work with all versions of records, enjoying the benefits of "schemalessness".

Primary Key
  • 1,237
  • 9
  • 14