new optional commandline switch for --update to specify destination path

[6arms1leg]

on some occasions (e.g. #212) the database has to be dropped and rebuilt. on slow home servers this can take a while (rpi ~ 2 days!).
i thought about a new commandline switch (that can additionally be passed on updates, something like --update --updatepath /new/path) that would make it possible to alter the destination path of the database that is created with the --update switch. that way the current database in place doesnt get overridden (or results in a conflict if overiding isnt permitted) and cherrymusic stays running fully functional (using the current database). of course this should be in combination with #195.
once the update is complete, there would only be a downtime of about 10 secs for replacing the old datatbase with the new one:

[cherrymusic is running fully functional using the current db...]

$ mkdir ./temp
$ cherrymusic --update --updatepath ./temp/

[2 days pass until db creation finishes...]

then 10 seconds downtime:

$ sudo systemctl stop cherrymusicd.service # or whatever way is used to run cherrymusic
$ cherrymusic --dropfile-db # this justs removes "~/.local/share/cherrymusic/db/cherry.cache.db", right?
$ mv ./temp/cherry.cache.db ~/.local/share/cherrymusic/db/cherry.cache.db
$ sudo systemctl start cherrymusid.service

done! the complete database was rebuilt with only a few secs offline.

for server use this would be a huge benefit.
what do you think? does that make sense or did i miss something?

[devsnd]

Well, I think it's a good option to have, but I don't think you should be able to set the path yourself. Rather it should be a switch that automatically takes care of that.

--update-swap-db would perform an update on another database, e.g. ~/.local/share/cherrymusic/db/cherry.cache.db.temp
and swap it in place when the update is finished. This could be done with almost zero downtime, since all the program had to do is to disconnect the old data base, move the new one into place and reconnect the data base, everything even without the need to restart the server. This would happen in under a second, even on slow systems.

Please let me know if you think the name for switch is appropriate or if could be made more clear.

[6arms1leg]

well, i didnt think of that. that would certainly simplify the process.^^
i like it.

[tilboerner]

Shouldn't it rather be possible to update the database while the server is running? #195 is pretty high on my must fix list.

If anything, there should be --backup PATH and --restore PATH switches, but that's another issue. 👉

[devsnd]

#195 is important, but this has nothing to do with this issue as far as I understand. If we have to break the integrity of the database at some point (while still having backwards compability for most of the requests) there should be a way to make that jump without 2 days downtime.

[6arms1leg]

Shouldn't it rather be possible to update the database while the server is running?

of course. updates should be possible while the server is running. but wheather that replaces this issue depends on how an update is done while the server is runnning.
when i wrote this feature request i had in mind that on some occasions (e.g. #212) the database has to be dropped and recreated completely. in that case the whole database has to be recreated.
not sure if a "update while online" feature would cover this.
if the database gets dropped first and then the update is done, its a different feature (because then even though the server is up and running i had to wait 2 days until i had full access to all files again)

so i think "update the database while the server is running" is a different issue. :-P

EDIT:

@devsnd was faster and nailed it with only one sentence. damn! 🙉 🙈 🙊

btw, schould we create an "update the database while the server is running" issue?

[tilboerner]

Ok, good point, I hadn't thought of that. But when we

break the integrity of the database at some point (while still having backwards compability for most of the requests)

the server should refuse to work with the old database version. I'd rather have it detect the incompatible layout upfront than let [threads crash | behavior be undefined] when the wrong kind of request comes in. Chances are that we need to recreate the database precisely because there is no backward compatibility; a case like switching the type of the rowid column like we're facing in #169 should be a pretty unique thing, right?

I agree that a 2-day down time is 💩, but if the update runs concurrently there'd be linear progress towards full service. Not really optimal, yes; but really I'd hope that a scenario like that should be rare enough not to warrant its own command line option. For that reason, I favor the solution originally suggested by @6arms1leg , but with a slight modification:

Create an option to configure the runtime data directory from the command line: --update --datapath XYZ.

That might also be useful for other purposes. (Also, make one for the config dir as well.)