implement SchemaEditor.add/alter/remove_field()

[timgraham]

Should these operations try to follow what Django does on SQL backends as much as possible?

For example, if adding a field with a default, Django will populate the default value on existing rows. Should MongoDB do it? If so, what about if there's no value to be populated? Should the field not be added to existing documents? We might be able to do that for nullable fields, but perhaps not for string-based fields where null=False and the default is an empty string.

[Jibola]

I'm willing to take a group vote here, but here's my take:

Questions:

if adding a field with a default, Django will populate the default value on existing rows. Should MongoDB do it?

Yes

If so, what about if there's no value to be populated? Should the field not be added to existing documents?

The field SHOULD be added to reduce bug issues; this is a point I am willing to discuss

My larger sentiment is let's keep to how Django handles SQL backends generally to reduce any potential errors that could arise from assumptions made elsewhere in the code.

Considerations :

• What happens when the data needs to be retrieved? If the value is empty, do we null out the field entirely?
  • If no field exists, then we may need a special object representation because None/null is a valid value that signifies a field's existence. Something like Undefined in JavaScript would need to be there. I think this is cumbersome and ultimately increases complexity in a system that didn't have this before. Ergo, it's more trouble that its' worth in an MVP iteration.
• What's the existing paradigm in MongoDB?
  • If you don't need it, don't put it there, really.
• What's the existing paradigm in SQL?
  • All rows and columns are explicitly defined so there is never an "undefined" row/column

[timgraham]

All migrations and schema tests are passing, except for indexes & unique constraints (tracked in #125).