-
Notifications
You must be signed in to change notification settings - Fork 606
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
Synchronization option now supports syncUpdateCondition to skip remote record #1548
base: master
Are you sure you want to change the base?
Conversation
Hi, this makes sense to me. I propose changing this to work more similarly to to conflictResolver - i.e. first the built-in
BTW I'm not sure if this is correct. It's arguable whether this is expected behavior, but I think that's a bug. I specifically added |
I can move it yeah if that is preferred. My thinking at the end was that it maybe belongs to
This puzzled me a bit as well. The thing is that Edit: Maybe |
Ok, rename it to |
description: 'remote', // remote change | ||
project_id: 'orig', // unchanged | ||
}) | ||
}) |
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.
it('forced local should keep record intact', async () => {
const { database, comments } = makeDatabase()
await makeLocalChanges(database)
await testApplyRemoteChanges(database, {
mock_comments: {
updated: [{ id: 'cSynced', body: 'remote' }],
},
}, {
conflictResolver: (
tableName: TableName<any>,
local: DirtyRaw,
remote: DirtyRaw,
resolved: DirtyRaw,
) => {
return local;
}
})
await expectSyncedAndMatches(comments, 'cSynced', {
_status: 'synced',
_changed: '',
})
})
will cause
FAIL src/sync/impl/__tests__/applyRemote.test.js (32.296 s)
applyRemoteChanges conflictResolver forced local should keep record intact
expect(received).toMatchObject(expected)
- Expected - 2
+ Received + 2
Object {
- "_changed": "",
- "_status": "synced",
+ "_changed": "updated_at",
+ "_status": "updated",
Atm synchronization only allows to customize conflict resolution which doesn't provide full control when trying for example to skip remote record altogether. It is possible to use conflict resolution that would return local but this is happening too late and has side effect of modifying updated_at.
… conflictResolver where appropriate, added tests
120d397
to
3fb82dd
Compare
3fb82dd
to
9ca6441
Compare
Atm synchronization only allows to customize conflict resolution which doesn't provide full control when trying for example to skip remote record altogether. It is possible to use conflict resolution that would return local but this is happening too late and has side effect of modifying updated_at.
edit - some more notes:
It is currently problematic to achieve idempotency when doing repetitive pullChanges. For example I would expect below code to be no-op but since potential local change will be resolved our updated_at will be updated. I am aware that custom "
updated_at
" could be used instead but that feels more like working against WatermelonDB.