Lab: Apply the Schema Versioning Pattern - [Needs Clarification]

MongoDB University M320: Data Modeling
#1

Hi folks,

I have problems with the solution of the lab “Apply the Schema Versioning Pattern” in Chapter 4.

In my understanding, the “schema versioning pattern” is a solution strategy for the situation of having an existing document structure and need to replace (a subset of) this structure (e.g. one attribute) without having the need of stopping the application, migrate all data to the new structure and then starting a new version of the application to work (only) with the new structure.
So it is more than just having documents with different structures in the same collection and having an application that can handle those different structures. It is also more than adding just some attributes to an existing structure and change the application to handle those additional attributes, if they are present.

So in my opinion, only scenario B is “best suited” for the “schema versioning pattern”, because scenario A just adds attributes and scenario C just holds documents with different structures in one collection.
But my answer was marked as “wrong”.

Could anyone please tell me if I made an error in reasoning.

Thanks in advance
Jochen

#2

Review the lecture about migrating strategy.
The answer is there.

#3

Hi Gianfranco,

thanks for answering so quickly.
I already reviewed the lecture a couple of times, but unfortunately I still didn’t get it :frowning:
Which part of the migration strategy should help me figuring out my misunderstanding?
If I add an additional field to a document (structure) and enable the application to handle this optional field - am I already applying the schema versioning pattern? I don’t think so.
Or is the schema versioning pattern just the fact that my application can handle different structured documents in the same collection? I don’t think so, too.
In my understanding, a key point of the pattern is, that an already existing information (attribute) is stored differently in a newer version of the document structure. Am I wrong with that?

Any further help would be appreciated.

Jochen

#4

Jochen,

I see your point that just adding new fields does not change the shape enough to justify labeling the version of the document.
There are cases where it is right.
We will modify the description of the lab to make it less ambiguous.

Thanks for the feedback,
Daniel.

#5

I agree with Jochen. It’s not that the scenario is “ambiguous” it’s that it absolutely does NOT fit the advice on when the pattern is suitable.

#6

+1 :white_check_mark:
In a controlled environment, any change to the structure of a schema in Production would require some downtime or at a bare minimum, a fail-over plan with a rollback strategy. And although MongoDB offers so much flexibility in that it is schema-less in nature, it doesn’t mean that it is schema-free. One might argue that this notion of schema-less collections is largely a concept that’s well suited to the Development phase of your DB for the purpose of Agility. See this blog from one of @danielcoupal’s colleagues that talks about locking down your schema. Furthermore, you would agree that (in a controlled environment), changes to a database is treated entirely separately from the changes required at the application layer and as a result, the former is what this design pattern prescribes.

As we’ve learnt from this course, Schema Versioning means that we’re creating different versions of a document without altering the schema of the existing one hence no downtime from a database change point of view. If schema validation is enforced, we will only need to either alter the schema validator to include the new fields, or turn it off/bypass, and then proceed to inserting the versioned documents. The decision of whether you drop the old documents or continue with a schema version control in place is down to requirements and has to be agreed between all relevant parties.

Therefore, in a controlled environment where adding a new column is deemed a change (and indeed a CR is raised), especially when the collection enforces schema validation, I would think that Scenario A suffices. There’s no doubt that the scenario in question could do with some further clarity which @danielcoupal has agreed to.

NB: One thing to bear in mind however is that, documents with different versions will have different auto _id values, so if this field is used as a $lookup to another collection, this will need to be handled.