Android Migration like Cocoa/Swift

[bsmn99]

Hi,

I just have a request,

why migration code is different from ios to android? in ios they just increasing the schema version and the altered table structure is updated automatically, but in android we have to write the migrate code for altered table as well as the schema version to be increased. Can u make in android too just increasing the schema number is able to alter the table? now its horrible to write migrate code for changes, and that too we have to make a track for what columns added, deleted and updated. Pls consider this..

[cmelchior]

Hi @bsmn99

It is also an discussion we had internally and there are good arguments for both types of migrations.

Be aware that the iOS migrations are not automatic in all cases and those corner cases are non-trivial to solve and will have to be maintained even for future migrations.

The Android migrations require more boilerplate code for sure, but they are write-once. After that you can forget about them and they will continue to work. Also we have plans for creating an IntelliJ plugin that can help with creating the migration code, making it less painful.

Note that if you do not want to keep your data across schema changes, you can always use RealmConfiguration.deleteRealmIfMigrationRequired(). For some use cases like offline caches, that is a lot easier as you don't have to write any migration code.

For the current future we plan to let iOS and Android behave differently in this area. That also enable us to gather more realworld input about both approaches.

[bsmn99]

Hi @cmelchior

Thanks for the clarification, expecting that IntelliJ plugin!..

[bsmn99]

@cmelchior

Be aware that the iOS migrations are not automatic in all cases and those corner cases are non-trivial to solve and will have to be maintained even for future migrations.

Can u explain what kind of corner cases for iOS?

[cmelchior]

A couple of cases:

a)
v1: Add new field name
v2: Remove field name.
v3: Add field name again. name should be empty here, not contain all the v1 data.

b)
v1: Add field email
v2: Rename email to contact
v3: Add field email again. This should now be empty while contact contains all the data

A good way to think about is that iOS always go from currentVersion -> latestVersion skipping any intermediate calculations while Android always go v1 -> v2 -> latestVersion, which means that all steps are applied. So if you are changing the same field across multiple migrations on iOS you usually have to be a bit careful. This is also described in their docs btw: https://realm.io/docs/objc/latest/#linear-migrations

[vonox7]

For the current future we plan to let iOS and Android behave differently in this area.

@cmelchior: As an app development company, we have to support of course both Android and iOS. Every difference between those two platforms makes our work much harder. Realm should make lives as a developer easier. Easier means less things to think about. So please decide on one way, but be consistent for all platforms.

[cmelchior]

One way to get around this could perhaps be to add two different RealmMigration interfaces:

public interface RealmMigration {
   public void migrate(DynamicRealm realm, long fromVersion, long toVersion);
}

public interface RealmAutomaticMigration {
  public void migrate(Migration migration, long fromVersion);
}

public class Migration {
  // Mimic Swift class: https://realm.io/docs/swift/2.4.0/api/Classes/Migration.html
}

That would allow us to support both ways of doing it without breaking existing support.