-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic handling of backlinks when migrating to EmbeddedObject #4729
Comments
Any update when this would be released? |
Hi @niralishaha25, this is just an improvement to automate things that already work manually. So, fortunately this feature is not necessary to solve your problem. Could you please create a ticket in the SDK you're using describing the problem in more detail and show some sample code? We can then help you solve this problem. Thanks! |
I couldn't find any API related to migrating embedded objects though went through multiple issues on GitHub. Thought this is the one which actual has user facing API. |
@nirinchev Which SDK are you using? If we know which language you are looking for we probably point you into the right direction. I've also created a little Q&A document for |
I am using realm-cocoa for iOS version 10.13.0 |
@niralishaha25 The Cocoa repository does have examples for migrations. |
@DominicFrei The sample doesn't show anything about how to do this migration. @niralishaha25 If you look at realm/realm-swift#7145 there is some info there that could be useful. Migrating to embedded objects is far from trivial I am afraid :/ |
After investigating this further, it looks like the case of removing multiple backlinks by copying data and assigning exactly one backlink isn't possible in the iOS SDK for the moment. I didn't understand the API to create embedded objects during migration so added a feature request here: realm/realm-swift#7508. But apparently it was re-labeled as a bug, so I don't think this is possible to do. In the Android SDK I have been able to do this without problems. |
Hi @sipersso, the other issue you created was turned into a bug because it is already supposed to work but doesn't. Hence bug not enhancement. It's just for our internal prioritization though, for you it's all the same I suppose. Something that you need is missing, sorry about that. We'll take care of this in the other issue so you can go ahead a finish your migration including EmbeddedObjects with multiple backlinks. 👍 I'll keep this issue here open as well since it's the automatic handling of all of this which will probably happen sometime after fixing the bug. 👍 |
Summary
Migrating a table from non-embedded to embedded is not really easy and obvious in the user-facing SDKs.
This could be improved by automating the main problems and making the migration easier for the user.
Motivation
When migrating a table from non-embedded to embedded users do struggle to get it right because they have to deal with two cases:
The struggle itself has two reasons:
MigrationBlock
(there are multiple questions about how to do that in Cocoa and .NET resulting in Helper function for migrating to EmbeddedObject realm-dotnet#2408 and Helper function for deleting orphaned embedded objects within migration realm-swift#7145).EmbeddedObject
in general which means they can't even be iterated while in a migration).While allowing the latter for the special case of migration would partial solve this, I'd like to propose the following changes to solve all those problems at once.
Goals
When applying the post migration changes we ensure the following during https://github.com/realm/realm-core/blob/master/src/realm/object-store/object_store.cpp#L832:
User-facing API
deleteOrphanedObjects
to the migration, typebool
. In the SDKs this would probably make most sense inRealmConfiguration
since theMigrationBlock
and theDeleteFilesOnMigration
flag already live there. In Core this might probably be best situated inObjectSchema
next toIsEmbedded
itself.false
so that it does not influence any existing migrations.The text was updated successfully, but these errors were encountered: