On Sat, 16 Dec 2023 16:54:38 -0800 Ian Eure <[email protected]> wrote:
> > If beets is built to expect other programs to access its > > database directly then this would work. > > > > Beets uses SQLite, which doesn’t support concurrent access at all, > even read-only. In practice, this isn’t much of a problem, > because beets is run infrequently, like when you want to add new > music. > > There are workarounds, such as copying the database or hard > linking it, both of which defeat SQLite’s locking mechanism. > Though hard linking isn’t portable to non-unix-like platforms, and > is fairly dangerous -- defeating the locking means that if either > EMMS or Beets writes to the .sqlite3 file, the other accessor will > likely blow up. Afaik SQLite and its python wrapper work quite well with concurrency in its write-ahead-logging mode (added back some 10+ years ago), but it has to be enabled via "pragma journal_mode=wal", which I don't think beets does. So I think it might be more of a beets code limitation at the moment. P.S. If you're curious about the difference, I've put up a patched-up old script which I've used to test python wrapper and its parameters here: https://gist.github.com/mk-fg/bcca57313c725c6ccceeacca959ae3bf With "-J wal" it works roughly similar to other db engines (which all use WAL by default of course) with any number of concurrent reader/writer processes. That doesn't affect how beets works ofc, unless someone changes it there. -- Mike Kazantsev // fraggod.net
