speed-up synchronization

[korelstar]

• switch from database.xml to migrations
• rewrite MetaService, add hooks for file changes, add CleanUp on app activation

From new MetaService documentation:

The MetaService maintains information about notes that cannot be gathered from Nextcloud middleware.

Background: we want to minimize the transfered data size during synchronization with mobile clients. Therefore, the full note is only sent to the client if it was updated since last synchronization. For this purpose, we need to know at which time a file's content was changed. Unfortunately, Nextcloud does not save this information. Important: the filemtime is not sufficient for this, since a file's content can be changed without changing it's filemtime!

Therefore, the Notes app maintains this information on its own. It is saved in the database table notes_meta. To be honest, we do not store the exact changed time, but a time t that is at some point between the real changed time and the next synchronization time. However, this is totally sufficient for this purpose.

Therefore, on synchronization, the method MetaService.updateAll is called. It generates an ETag for each note and compares it with the ETag from notes_meta database table in order to detect changes (or creates an entry if not existent). If there are changes, the ETag is updated and LastUpdate is set to the current time. The ETag is a hash over all note attributes (except content, see below).

But in order to further speed up synchronization, the content is not compared every time (this would be very expensive!). Instead, a file hook (see OCA\Notes\NotesHook) deletes the meta entry on every file change. As a consequence, a new entry in note_meta is created on next synchronization.

Hence, instead of using the real content for generating the note's ETag, it uses a "content ETag" which is a hash over the content. Additionaly to the file hooks, this "content ETag" is updated if Nextcloud's "file ETag" has changed (but again, the "file ETag" is just an indicator, since it is not a hash over the content).

All in all, this has some complexity, but we can speed up synchronization with this approach! :-)