[GH-ISSUE #3] Synchronize issue: offline edits to removed objects #1

New issue

Closed

opened 2026-05-23 08:33:41 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-23 08:33:41 -06:00

Owner

Originally created by @appy-one on GitHub (Mar 3, 2021).
Original GitHub issue: https://github.com/appy-one/acebase-client/issues/3

Originally assigned to: @appy-one on GitHub.

When using AceBaseClient with a local cache db, the following can occur:

client1 makes changes to an object while offline
client2 removes the object while online
client1 goes online, pushes its changes to the server
A "broken" object is now stored in the database

Example:

Consider a contact in the db: { name: 'Ewout', email: 'me@appy.one', phone: '+31612345678', last_called: (date) }

client1 updates last_called while offline:

db.ref('contacts/ewout').update({ last_called: new Date() });

client2 deletes the contact while online:

db.ref('contacts/ewout').remove();

client1 goes online and pushes the change to the server. causing the stored contact to be "broken": { last_called: (date) } because it was re-created by client1's update.

This should be prevented somehow.

Originally created by @appy-one on GitHub (Mar 3, 2021). Original GitHub issue: https://github.com/appy-one/acebase-client/issues/3 Originally assigned to: @appy-one on GitHub. When using AceBaseClient with a local cache db, the following can occur: * client1 makes changes to an object while offline * client2 removes the object while online * client1 goes online, pushes its changes to the server * A "broken" object is now stored in the database Example: Consider a contact in the db: ```{ name: 'Ewout', email: 'me@appy.one', phone: '+31612345678', last_called: (date) }``` client1 updates ```last_called``` while offline: ```js db.ref('contacts/ewout').update({ last_called: new Date() }); ``` client2 deletes the contact while online: ```js db.ref('contacts/ewout').remove(); ``` client1 goes online and pushes the change to the server. causing the stored contact to be "broken": ```{ last_called: (date) }``` because it was re-created by client1's update. This should be prevented somehow.

gitea-mirror referenced this issue

2026-05-23 08:33:42 -06:00

[GH-ISSUE #1] OAuth provider signin fails after redirect #3

gitea-mirror closed this issue

2026-05-23 08:33:42 -06:00

gitea-mirror commented

2026-05-23 08:33:45 -06:00

Author

Owner

@appy-one commented on GitHub (Mar 18, 2021):

I'm currently testing moving schema validation from acebase-server to acebase, so it can be done at storage level. This could prevent those broken nodes to be created, while also making schema validation possible for standalone databases without a server endpoint. Schema validation would then also become available for IndexedDB databases in the browser.

@appy-one commented on GitHub (Mar 18, 2021): I'm currently testing moving schema validation from ```acebase-server``` to ```acebase```, so it can be done at storage level. This could prevent those broken nodes to be created, while also making schema validation possible for standalone databases without a server endpoint. Schema validation would then also become available for IndexedDB databases in the browser.

gitea-mirror commented

2026-05-23 08:33:45 -06:00

Author

Owner

@appy-one commented on GitHub (Mar 24, 2021):

Schema validation is now available in acebase v1.3.0
Next step is to update acebase-server to use the schema validation in acebase and remove its own validation code.

@appy-one commented on GitHub (Mar 24, 2021): Schema validation is now available in `acebase` v1.3.0 Next step is to update `acebase-server` to use the schema validation in `acebase` and remove its own validation code.

gitea-mirror commented

2026-05-23 08:33:46 -06:00

Author

Owner

@appy-one commented on GitHub (Mar 26, 2021):

acebase-server now uses acebase's schema validation. The "broken object" issue can now be prevented by setting schema rules.

@appy-one commented on GitHub (Mar 26, 2021): `acebase-server` now uses `acebase`'s schema validation. The "broken object" issue can now be prevented by setting schema rules.