-
Notifications
You must be signed in to change notification settings - Fork 169
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
Upload data and migrate schema #6944
Upload data and migrate schema #6944
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good - just a few comments.
if (auto self = weak_self.lock()) { | ||
util::CheckedLockGuard lock(m_mutex); | ||
if (!m_session) | ||
return; | ||
m_sync_schema_migration_required = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there ever a case where weak_self
could be locked but the this
pointer is not valid? I can't think of any.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's really possible either
#if REALM_ENABLE_SYNC | ||
if (m_config.sync_config) | ||
return; | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this check for? Is it to make sure it is not a sync'ed realm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah. didn't want to break the behaviour for local realms.
return; | ||
} | ||
|
||
std::shared_ptr<AsyncOpenTask> self(shared_from_this()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a comment that you are extending the lifetime of this object until the bootstrap is complete?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a comment. we've already been doing that with the initial subscriptions callback.
std::function<void()> callback; | ||
{ | ||
util::CheckedLockGuard l(m_state_mutex); | ||
callback = m_sync_schema_migration_callback; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you "move" or clear the callback when you grab it to call it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, let's do that.
* Main work of sync schema migrations * misc * Code review changes
* Main work of sync schema migrations * misc * Code review changes
* Main work of sync schema migrations * misc * Code review changes
* Main work of sync schema migrations * misc * Code review changes
* Add schema version to flexible sync client BIND message (#6863) * Send schema version as part of BIND messages * Add pause_async to SyncSession (#6845) * Add async shutdown of SyncSession * SyncSession::shutdown returns a Future instead of passing callbacks around * Rename shutdown() to pause_async(). Hide it from the public API. * Remove unneeded header import * Upload data and migrate schema (#6944) * Handle client resets during schema migrations + integration tests (#7106) * Add option to use draft deployments when creating a schema for baas tests * Track sync schema migration between sessions + minor refactoring * Integration tests * Bump sync protocol version to 11 * Update baas commit for evergreen tests * Allow resetting schema version to zero * Improve changelog
What, How & Why?
This is the main body of work for sync schema migrations.
A schema migrations is performed whenever the client receives
schema_version_changed
error (236) from the server. In such cases, the synchronization session is left active so any unsynced changes are uploaded to the server before migrating the schema. The realm file is then deleted and reopened at the new schema version. Data is bootstrapped at the new schema version.These are the steps the client and server take in case of a schema migration:
Note: Schema migrations can only be performed when a realm is opened asynchronously.
Fixes #6842.
Integration tests will be added in a separate PR.
☑️ ToDos
[ ] 📝 Changelog update[ ] 🚦 Tests (or not relevant)[ ] C-API, if public C++ API changed.