search

woefe / ytcc

Command line tool to keep track of your favorite playlists on YouTube and many other places.
GNU General Public License v3.0
179 stars 20 forks source link

Create a v1 to v2 migration script #50

Closed EmRowlands closed 3 years ago

EmRowlands commented 3 years ago

This PR adds a set of migration scripts that can be run to populate a v2 database with the data from a v1 database.

This PR is marked WIP, since it is undecided as to where the script itself should go. It's possible that export_db.py could be merged into a feature for a new v1.8.6 release, and import_db.py could be merged into the main v2 tree.

Closes: #42

woefe commented 3 years ago

Thank you so much for your PR!

I think we can probably not expect that users still have v1 installed. I think most users will just blindly update and then see the v2 command fail with the warning that the database schema is incompatible. I'd prefer a script that does not need v1 installed and can also be used without cloning stuff from GitHub.

I'll hack something together and create another PR. I see that you took care of some edge cases that I would probably have missed. When I create a new PR and you find time, would you review and try it out?

EmRowlands commented 3 years ago

I would gladly review it. I think the easiest way of doing this would be to just take the contents of export_db.py and import_db.py and put them straight into new CLI subcommands in v1 and v2, respectively. I just didn't do this when creating the original code, it was just something quick and dirty so I could try out v2.

If you want, I can splice out the separate parts into a PR for v1 and a PR for v2, implementing export and import as functions, then you could finish them off by writing the appropriate argparse/click wrapper stuff. It's up to you whether you or I do it.

woefe commented 3 years ago

I'd rather have it in a separate script than in ytcc v1/v2 itself. The problem is that v2 won't start if it encounters an old database. Hence, you would need to adjust your config before migrating, adding another step to the migration procedure, which is already not soo user-friendly. And moving some parts to v1 won't solve the issue that users upgrade to v2 without knowing it is incompatible and then not having access to v1 anymore. (Of course users could downgrade, but that's annoying)

EmRowlands commented 3 years ago

Obsoleted by: #51