Schema Versioning - implementation

Hi.

Question about strong typed languages (e.g. java or go-lang) - Is there any idea how to implement the schema versioning pattern in these languages? usually, new document structure means new class/structure. But when marshaling the bson into an object, you have to first know the version, but it’s part of the bson data, so you don’t know it. If the change is only an addition of new fields - that easy to implement. But if the change is refactoring the document, changing field type etc. then I don’t know how to do that, beside reading the document into a map and then create the right object from it. But I don’t think it too optimise solution.

What do you think?

2 Likes

I don’t know if I have well understood your question, but sometimes when we are dealing with refactoring in data base schema it will reflect another refactoring in you code repository. It will probably be a one-to-one refactoring.

Example:

Suppose that your application has the following class:

/**
  * A POJO class that represents a single person in the app.
  */

@Data // lombok annotation
class Person {
	private String name;
	private Date birthDate;
	private String id;
	// ...
}

and objects of this class are mapped/stored as the following documents:

{
  "name": "Someone",
  "birthDate": "1900-01-01T00:00:00Z",
  "id": "8794568979"
}

Now, suppose that you need to change the type of id to be a long instead of a String.
Probably you will need to do that change in both.
These changes will cause a new versioning of your source code repository (ex: v0.0.1 to v0.0.2) and this change will be reflected in documents that will be used with the new version of your app.


I hope I helped you!

I know this is old, but to give an answer the people who end up here, a solution would be to implement a pattern on your application that can deal with this. I suggest using the factory pattern.

1 Like