If you check the activity on GitHub, you will see most of the team is working on the feat/db branch i.e. on the “database version” for the last year or so.
I think they realized the current implementation of storage is impossible to fix and they decided to introduce a DB, it seems SQLite compiled to WebAssembly, and use it as the reliable storage. Then, to my understanding, they will develop a background service that sync the DB with the Markdown/Org files, making changes propagate in the two directions.
While I totally understand your frustration and I am very scared to lose data, I think we can say the team is aware of the situation and their focus is on fixing the root cause of all these issues.
I tried the DB version in the browser and the new properties are exactly what I wanted. Also, to my surprise, when I reopened the web page days later, my test graph was still there, probably stored locally in my browser.
I can’t wait for reliability and the new properties, I’d really need them now, but we have to wait and eventually be careful when using Logseq now.
Bizarre, I’ve been using Sync religiously for the last 5 months for both personal and business purposes - and have not had any problems like this.
Are there any other factors in play here, such as having Logseq open/active on another device at the same time or opening more than once instance of Logseq on the laptop? I once opened two instances of logseq with sync enabled (one just to read-only on another monitor) and this was causing me to receive a merge popup quite frequently.
I’ve had Logseq Sync turned off for 5 days. Just turned it back on and watched it wipe out literally every single edit I made today. I watched it do it. I have git backups to Github so I’ll just roll back my git repo to the commit before Sync destroyed my data.
I don’t have multiple windows open. The only plugin I’m using is AwesomeStyler. Everything else is vanilla out of the box. And this isn’t some weird, anomalous, non-deterministic defect. I can repeat this behavior every time.
Turn sync off
Make edits to some pages or journals
Turn sync back on
Watch edits disappear
Every single time.
It doesn’t seem to happen if I have Smart Merge turned on. If I have Smart Merge on, then all sorts of blocks and page property values get randomly duplicated all over my graph. So I can choose data loss or data corruption. Those are my only options with Logseq Sync. Which I pay money for by the way.
To put it politely, this feature is garbage. The fact that they don’t have this as an automated test case gives me exactly zero faith in the Logseq team. Or even worse, they do have it as a test case and released this anyways. I’ve logged a crap ton of issues in their Github repo and have gotten exactly no replies. No triage. No follow-up. And they certainly haven’t actually addressed any of the issues I’ve logged.
I hate that I’m so invested in this software. It’s so very poorly implemented.
You got it wrong, you are not paying for the Sync service, you are contributing to Logseq “community fund” and as a reward they let you try beta or alpha features (depending on how much you donate), you are supposed to test it, they are supposed to consider your feedbacks and only later Sync will become a paid service.
The whole Logseq is in beta, not only Sync. We are not supposed to use it in production until version 1.0 is released. It’s just that Logseq is already good enough that we all want to use it in production. But the truth is that we are early adopters helping with the development of a future product.
Is Logseq taking too much time to release a 1.0? Maybe, maybe not: it has been ~3 years since the first release and ~2 years since a team has been put together. 2-3 years is already the time most commercial proprietary software need to be launched anyway.
So the way I see it, the FOSS model is giving use the priviledge to try some software while it is being developed and to contribute to it.
There is still a chance Logseq team will fail and Logseq will be abandoned but it doesn’t seem the case at the moment, they have a plan, it’s a long term one, only time will tell if they were right investing so much time, particularly the last year on the DB version.
When you require that someone gives you money in order to access a service or product, the term we use for that in English is “paid for”. Give it whatever apologist semantics you want. I’m giving them money in exchange for a service which has been touted as “beta”. In my 30 year career in software development, I’ve never been allowed to call software “beta” if it destroys or corrupts user’s data. That’s table stakes.
And in case anyone’s keeping track at home, the data I had to restore twice yesterday is … gone again. I had to restore again today. So not only does it destroy data, it destroys data that I’ve recreated. 3 times.
Early access to new features is a common thing, Obsidian for example requires a one-time payment of 25$.
It seems you have a bug that trigger this behavior but as you may know, the team can’t do anything until they will be able to reproduce the bug and as I said their plan seems to be releasing the DB version as soon as possible instead of trying to fix all the bugs people are finding now.
Yet another thread of people losing their work (plus time, etc)…
And I just realized that I resigned myself to only use it for really loseable stuff - which ends up in duplication across other programs, making me doubt myself (did I write that down? Where did I put it? Oh gosh, maybe it got lost by Logseq?), stopping myself from using it across devices, etc.
In other words - sync is worse than useless like this. So ironic to pay for an organizer that ends up making things messier. The Logseq website introduces it saying " constantly afraid of losing your thoughts"? Well yes, thanks to Logseq!
And devs stay mum.
Enough complaining, I’m cancelling my subscription right now.
Thank you so much for the correction. You’re right, Open Collective calls it “periodic contribution”, not subscription.
Not sure what does that matter, but I cancelled it anyway.
Let’s see if Logseq / its back-end is coded well enough to even realize before the periodic re-login-request
Synchronization of information is one of the difficult problems in computing, so I’m not surprised of these issues.
I’m personally moving from Joplin not only because of the superior knowledge management LogSeq offers but also because their synchronization methods are failing on my case (I have more than 5000 references, it gets confusing).
I’m perfectly happy using git for commit-push for external storage, and pull-commit-push for synchronization with a second computer and advise anyone, even if using another method, to use git as a means to fast data recovery.
This is a fair comment, but their website doesn’t mention this on the home page. Indeed, it labels two specific features (sync and whiteboards) as being in Beta, which to me would naturally imply everything else is out of beta.
My personal issue is that Logseq was pretty reliable, I used it daily, and now it’s not reliable at all. New releases seem to create new critical bugs to the point that I have had to switch to another solution.
It may be worth noting that it is possible to agree with both ends of this conversation: corruption of data is a major deal, and the website should be more clear about the current state of the software so users are aware of the risk level and maybe which specific operations to avoid to improve their chances.
At the same time, Logseq is still in its early days, and I’d guess that many people that donate to the project are doing this for realizing that it takes a lot of work to take something like this off the ground, and we’d all benefit if such a key daily driver software continues to be developed in the open and reaches maturity. We’re not paying to use the software. We’re rather contributing for the software to exist in its intended form.
Stopped using the internal sync and started using Syncthing for peer to peer synchronization. Next step is having an own raspberry as data center for distribution and backup. That is currently my way on dodging the non-realiability of the internal sync feature. Anyways i actually intend to not rely on a centralized sync service.
Looking at the current state I think that next to sync it should really have things like a frequent backup to avoid people making assumptions on it’s reliability. It does so in limited fashion in logseq/bak but it’s all far from perfect.
Logseq is clearly aware though, if you mess around in things like the DB branch you sometimes get blocked from removing/changing things to avoid data loss. This type of, avoid shooting your own foot, tells me there’s a departure from the developer mindset go fast and break things to a more user mindset where it’s slower but more reliable.
Thanks for the clear steps, I’m going to see if I can break my own sync for a bit.
