Polymorphic Subdocuments

MongoDB University M320: Data Modeling
#1

In the video lecture for the polymorphic pattern: the slide and material discussed how to use the “country” field to determine the type of address.

Polymorphic_Subdocuments
Polymorphic_Subdocuments2126×1194 243 KB

Writing the “country” field last in the address sub-documents makes sense from a human readability point of view as this is where we would expect it when reading or writing an address by eye.
However there is a downside to positioning a ‘type discriminator’ field like this last. This becomes apparent when using a “reader” style decoder as described at this link: http://mongodb.github.io/mongo-java-driver/3.0/bson/readers-and-writers/

In code we want to encounter the ‘type discriminator’ field as early as possible when traversing through the fields. This allows the correct sub-document codec to be determined early.

My advice has been to put a discriminator field either first or second (after an id) or as the last ‘common’ field. For example in the address sub-document this could be after “city”. This would more closely resemble the position used in the ‘schema version’ pattern examples.

This design decision isn’t important when using a Document or dictionary based decoding approach but becomes relevant if using or migrating to the Reader style.

Suggest including a few words on this for future courses if you agree and would like students to consider this slightly subtle point when designing their schemas.

Thoughts?

Thanks!

#2

It would be an atypical assumption to think the fields in the document would be ordered in a given way. In other words, I am saying that the order is not important when stored in BSON on disk.

If you are implying that you want to write custom readers and writers and not use the high-level ones in the driver, we can argue that in the phase of data modeling, this should not be a consideration.

On the other hand, it is a good suggestion to move the “country” field higher in the example to make it clearer to illustrate the pattern.

Daniel

#3

Hi,

The fields are indeed stored (and returned) in a very well defined order. See http://bsonspec.org/spec.html

BSON is a binary format in which zero or more ordered key/value pairs are stored as a single entity. We call this entity a document .

In my experience this should be kept in mind when developing the schema (as it could be expensive to change later).

Thanks
Jason