Migration Handling: New Attributes

[jleandroperez]

After a (Light / Heavyweight) migration, the Data Model might get:

Attributes Removed:

This is currently supported, and no further action is required.

Attributes Renamed:

If we are to support backwards compatibility, the app needs a mechanism to map the "Remote Attribute Name" into the "Local and New" attribute name. We'll add support for this, in Issue #480.

Attribute Addition:

The first client that gets 'New Attributes' will work without further issues. But if there are (still) clients using the old data model, any changes they get over the "New Attributes" will, expectedly, fail.

In this particular case, the Ghost Data is expected to be updated, nevertheless. Let's implement a mechanism that:

• Detects that a migration has occurred
• Goes through the Ghost Data, and attempts to populate the "Newly Created Fields" (that were already being in use by other clients)

[prvnl]

Hi @jleandroperez,

Nice to see all the improvements and continued development on the framework!

Keep up the great work!

Regards,

Patrick

[jleandroperez]

Thanks for the feedback @prvnl!! Hope you're doing (more than) great sir!

[danielr]

Just one thought: Rather than detecting migrations (not completely sure if this is possible in the extend you'd need), what about saving the failing changes (those that cause the applyDiff for a member that doesn't exist warning) in some queue and once the attribute gets available (which you could check upon every cold launch, for example), try to replay them?

But, then again, I have no idea of how the internals of Simperium work, so that's probably not very useful. ;-)

[jleandroperez]

@danielr the remote state (should be saved) within the ghostData field.

Perhaps migrations could be detected by means of NSStoreModelVersionIdentifiersKey (that, as far as the documentation tells, should live within the NSPersistentStore's metadata.

On migration we could just fire a process that (perhaps) would detect added fields, and replay the remote changes.

This definitely requires a bit of R&D, but at first glance, seems achievable!. Thanks for your feedback!