Before this change we were adding them to cache before they were
processed, potentially persisting malformed entries, or entries we
haven't yet processed causing issues if sync was aborted before an entry
was fully processed.
Commit 5d1c90dcba fixed a bug where
entries added from the server were marked as "local only" (null etag)
which was causing issues. That commit fixes it for newly added resources,
but existing resources remained broken.
This commit goes through the database and fixes all of the existing
broken resources. It skips dirty entries because figuring out if they
were just created or updated is complex, and the chances of doing an
update at exactly the same time there are dirty entries is quite low,
so the complexity involved is just not worth it.
Before this commit we would create new entries from the server without
an etag, essentially marking them as "local only". While the actual
value of the eTag is not currently used, null or not matters.
Because the resources were "local only", we would get weird behaviours
like having an "ADD" action when changing a resource.
Before this change we would only add "deletes" to the server when the
resource has been previously uploaded. This means that if a resource has
been created and then deleted before a sync, it would not be saved,
which is essentially data-loss.
This commit fixes it, so we always upload a delete entry.
It's really annoying that it doesn't do it automatically as it should,
in the meanwhile, add this workaround.
I reported it to upstream:
https://github.com/requery/requery/issues/487
Clearing the cache is a good idea regardless, though because of the
unique constraints in the cache on the journal name, this was causing
issues when deleting an account and then adding it back.
It's very raw and hacky at the moment, it's just a preview release so
people could see their data is saved, and can look at it in its raw
form until we implement a nicer view.
Before this commit it was only used to override the api endpoint,
not it's also used to override the weburl. This is needed since we now
load the etesync website inside the app and not in an external web
browser.
Without this change, if the putting on server of a new collection fails,
the url would already be updated, and since having a url indicates it
exists on the server, trying to save it later would result in a 404.
