Hi, I noticed that when I add an object with optional fields using Swift Realm SDK - Device Sync writes null for those fields in the Mongo Database. This actually takes some disk space and it looks like there is no harm in removing those fields from objects. Is there a way to achieve this using Swift Realm SDK?
Currently, I just execute a cleanup function from time to time.
The question is a little unclear; optional properties can contain a value or be nil (in Swift). Atlas represents nil as null on the server, however the field itself still exists within the object schema (object graph)
I think is that comment is where the unclarity lies - how do you propose removing the fields while still maintaining that optional property as part of the object graph?
Do you mean just remove the property from the object entirely as it will never have a value (e.g. an unused property)? If so, sure, you can freely alter and edit your object graphs while in development - keeping in mind destructive changes may require a sync restart and/or client wipe and re-sync.
If the app is in production, it can still be done as well, although a bit more work.
The’s an entire section in the getting started guide covering Changing an Object Model
If the use case is something else, can you clarify?
Thanks for the reply @Jay. Sorry for the unclarity. Here is a real word example.
I added an object with optional fields having a nil value. Then I check what it looks like in the MongoDB:
There are c, r, and y optional fields containing nil value and are stored in the MongoDB as nulls. This object size is 111B. Now, I can just manually edit this object in the MongoDB and delete those fields:
The resulting object size is 102B so I just freed ~10% of storage space and everything still works as expected. If I check the object in the iOS app those fields will be nil. So the question is: is it possible to somehow store optional values as “absence of a value” instead of putting null there?
Hmm. If B means bytes and one object is 111 bytes and the updated object is 102 bytes, that’s a difference of 9 bytes. Thats a pretty small amount of space, even over a large dataset.
If the properties are not needed then remove them (per above) from your object model in your app!
Otherwise, if the schema on the server is altered and does not match the client, I would imagine at some point it will cause a client reset which would erase the data on the client and align it with the server.
However, the object models won’t match and well - that’s probably unrecoverable OR the server will add the fields back into future objects going forward to match your client graph.
It would be a good idea to read this Breaking vs. Non-Breaking Change Quick Reference.
Looking at the chart, far right “Remove a property in Atlas” is considered a breaking change and would require sync to be terminated along with other steps.
Along with that, it seems this section Remove A Property directly addresses what’s being asked
If you remove a property from the server-side schema, it is a breaking change. For this reason, we recommend that you remove the property from the client-side object model only and leave it in place on the server-side schema.