Hacker News Reader

Comment by ZenoArrow | Hacker News Reader

How does MongoDB handle schema changes? For example, let's say I want to add a mobile phone field to a customer record type. How would I go about doing that in MongoDB?

View on HN

The short answer is: just do it. You can add any field to any document at any time. That's the beauty of JSON documents without schema constraints. Then of course you need to let your application understand that. But it turns out it's almost trivial to make an application display a phone number field if it finds one, and not display a phone number if there isn't one in the document.

This is true

It hurts when the next requirement comes along something like...

"As a user I want to have a home, work, and mobile phone number"

Now you have 3 "versions" of your implicit "schema" to contend with

1) No phoneNumber 2) phoneNumber and mapping it into / out of one of the three phone numbers in the UI 3) objects with three properties homePhoneNumber, workPhoneNumber, mobilePhoneNumber etc

Then the business comes up with "As a user I want to have arbitrary phone numbers that I can label" now the developers start to squeal

RDBMS + SQL is no panacea but having DDL operations like the following (all probably syntactically invalid but you get the idea) out of the box is incredibly powerful. ALTER TABLE user RENAME COLUMN phone_number TO home_phone_number; ALTER TABLE user ADD COLUMN work_phone VARCHAR(32) NOT NULL; CREATE TABLE phone_number (id BIGINT NOT NULL, user_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, phone_number VARCHAR(32) NOT NULL);

I have had reasonable success using MongoDB as a store of "things that happened" and will never change

And I would still claim that this is easier in MongoDB because several versions of the phone number field(s) can happily coexist in the same collection. Those variants are usually trivial to understand for someone who even just looks at the data, and the application can be written to either accept the different formats, or adjust the format on the fly when it encounters a document that still uses an old schema. Or you could indeed write a batch job that bumps all your phone numbers to a new format, and you could put a JSON schema constraint on your collection that enforces the new schema for every future document. All those possibilities exist, and I truly see that as a big advantage.

The onerous is mostly on the developer...

For any "real" system that is going to be in production for a long time this becomes a real problem

There are tools to "migrate" data but they come with all the limitations of the Mongo isolation model

Typically you either

* Write ad hoc (possibly using some tooling) code to iterate over your old data adding or mutating the field(s) in question

* Write queries such that they can handle the data being present, absent or in different forms for all of time. As you could expect this is a large burden

Reply on news.ycombinator.com