Why is syncing designed to be so confusing/daunting?

[jsauerland]

I'm quite new to Trillium, having just ditched OneNote. I downloaded Trillium, it's brilliant, a bit complex, but usable. However, the issue is with syncing across devices. I check out a "simple" guide, and it goes into sync servers and network topology, server information, and is absurdly technical....

Why is it designed to be so confusing or daunting? I highly suspect that this will limit the usability of the software, as it's a bit too daunting for less tech-savvy people to understand. Is there a way to simply add it to onedrive, or a python/other kind of script to upload a backup of files to a folder in cloud?

[sigaloid]

The syncing wiki is intended for power users who know how to self-host this software. You cannot sync it with a cloud storage platform because they will corrupt the database. https://github.com/zadam/trilium/wiki/FAQ#can-i-use-dropbox--google-drive--onedrive-to-sync-data-across-multiple-computers

[zadam]

Unfortunately there's no perfect solution here. As linked by @sigaloid, the general purpose syncing solution like onedrive tend to corrupt files (if they are currently being open in the app).

A possible "solution" would be to use flat text files instead of a database which would minimize the risk and consequences of data corruption from e.g. OneDrive. But using a filesystem brings another set of problems.

The world is made out of trade-offs and I chose these ones. As a result, to set up the sync, you need to have some technical skills.

[soulsands]

(if they are currently being open in the app).

If the only problem is that it can't be occupied/open, would be possible to implement a mechanism temporarily cutting off the connection and locking the database, then sync the file manully, which is still better than not being able to sync. It increases the risk, though.

[soulsands]

This would be probably quite fragile and inefficient. Trilium won't know when does it have to close the connection for sync, so it would have to spend most of the time unconnected while checking if it was updated.

Emm, I was thinking Trilium don't have to check if it is should update, users do the operation. Trilium provides a button, after clicking it, trilium close the connection after everything done, and lock the database preparing for sync.

Also, these general sync systems won't be able to efficiently sync multi-GB database files. There's no good way to make a reasonable diff on a database file.

I'm not sure, but could trilium do the diff itself? I'm think about a mechanism that extracts the incremental part changes to a smaller file with a record, and another clients consume the files by the records, similar to the db migration in trilium.

[zadam]

Emm, I was thinking Trilium don't have to check if it is should update, users do the operation. Trilium provides a button, after clicking it, trilium close the connection after everything done, and lock the database preparing for sync.

And then open Google Drive, manually activate the sync, wait for it to finish, stop Google Drive, click the button in Trilium.

Seems very user unfriendly.

I'm not sure, but could trilium do the diff itself? I'm think about a mechanism that extracts the incremental part changes to a smaller file with a record, and another clients consume the files by the records, similar to the db migration in trilium.

I guess something like this is possible in theory, but very awkward and difficult in practice.

[soulsands]

Seems very user unfriendly.

Maybe it's better using git for syncing files, trilium can handle the files then.

I guess something like this is possible in theory, but very awkward and difficult in practice.

That would be great if there is an adapter that handles the preparations, reusing the current sync mechanism.

[sigaloid]

Here's a relevant wiki article: https://github.com/zadam/trilium/wiki/FAQ#why-database-instead-of-flat-files

[soulsands]

Here's a relevant wiki article: https://github.com/zadam/trilium/wiki/FAQ#why-database-instead-of-flat-files

I may not express well in english, I was trying to discuss the workaround for the limitations of database storage in trilium.