aw-server-rust icon indicating copy to clipboard operation
aw-server-rust copied to clipboard

Changes to database required for syncing

Open ErikBjare opened this issue 6 years ago • 7 comments

A couple of things:

  • We need to be able to create instances of the database that do not migrate/update like the local instance does (to ensure that they are readable by versions of aw-server-rust that are not up-to-date)
  • We need a way to enable read-only DB access

Thoughts @johan-bjareholt?

ErikBjare avatar Aug 28 '19 11:08 ErikBjare

We need to be able to create instances of the database that do not migrate/update like the local instance does (to ensure that they are readable by versions of aw-server-rust that are not up-to-date)

Maybe look at the schema version and if the schema version is not the same as the current one we should make a user-visible warning that the db from another instance is older/newer?

We need a way to enable read-only DB access

Agreed!

johan-bjareholt avatar Aug 28 '19 12:08 johan-bjareholt

Maybe also make a unique identifier for each computer? Or should we continue using hostname and simply refuse if two machines have the same hostname?

I'd prefer using hostname because it's more human readable, but I can also see the issue with it so my stance on that question is neutral.

johan-bjareholt avatar Aug 28 '19 12:08 johan-bjareholt

I realized that the whole mpsc thread model is a bit excessive if we are to only have read access to the database, so I rewrote the datastore code to be able to more nicely work without the worker.

https://github.com/ActivityWatch/aw-server-rust/pull/65

I would suggest to adapt the syncing code to create a read-only SQLite connection itself instead of going through the worker by only using the DatastoreInstance.

johan-bjareholt avatar Sep 14 '19 08:09 johan-bjareholt

Maybe also make a unique identifier for each computer?

I think we should at some point as people have already had issues with this (https://forum.activitywatch.net/t/remove-host-computer/358). Syncthing does it by generating a GUID for every host, possibly derived from the hosts public key.

I opened an issue about it: https://github.com/ActivityWatch/activitywatch/issues/302

ErikBjare avatar Sep 16 '19 08:09 ErikBjare

We need to be able to create instances of the database that do not migrate/update like the local instance does (to ensure that they are readable by versions of aw-server-rust that are not up-to-date)

Fixed in #76

johan-bjareholt avatar Dec 26 '19 14:12 johan-bjareholt

Fixed in #76

I appreciate it, but I kinda think that the solution you proposed was better (and is how Syncthing deals with nodes of different versions):

Maybe look at the schema version and if the schema version is not the same as the current one we should make a user-visible warning that the db from another instance is older/newer?

ErikBjare avatar Dec 28 '19 17:12 ErikBjare

I appreciate it, but I kinda think that the solution you proposed was better (and is how Syncthing deals with nodes of different versions)

If you look at the change you can see that this does both, the added "migrate_enabled" parameter does the following:

  • If set to true, same as previous behavior
  • If set to false it does not migrate. If the version is incompatible it returns a "OldDbVersion" error so we can notify the user gracefully to update

johan-bjareholt avatar Dec 28 '19 21:12 johan-bjareholt