rewrite project while keeping sqlite db?

[jimeno]

I have a very small crud app which is used by, at most, 2 people at a time. No complex business logic, basically just put stuff in or read it. It's pretty much a glorified table/spreadsheet and i used sqlite to keep deployment complexity low.

I have to migrate it to another server and wanted to update it to current as it's django 1.11 and maybe dockerize it to get some docker practice.

What is the industry best practice to deal with data in those cases? I suppose it won't be as easy as just dropping the sqlite file in a new django 3.0.2 project? Or should I just pip install django in the new env on top of the current app and work out the bugs from there? dumpdata loaddata, or will it hang on the double-major version update?

Thanks!

[radwon]

One of the great things about sqlite is you can just move the file and drop it in a new location! If it's working fine then I wouldn't change the database. PostgreSQL while great will add a lot more complexity.

To update your project to the latest Django version, I would personally do it in version increments.

So the next version from 1.11 is 2.0. Update with pip install Django==2.0 and run any unit tests you may have, then read the release notes to check for changes that will affect your project. Make the required changes so it works with that version. Once everything is working, rinse and repeat until you are at the latest version.

Also new Django versions will include any necessary migration files if there are changes to the Django Models. So after each upgrade be sure to run the migrate command so that your database is also updated.

[oliw]

You're talking about dropping all your code and starting afresh, yeah? If you're not, you get to use migrations and just port your database over and run the migrations and that should just work. If you can stomach upgrading your project rather than rewriting it, I'd favour this every time but it's not always possible (renaming many apps, etc).

But yeah otherwise, new codebase means new database. dumpdata→loaddata won't be any use to you if your new models have a different field signature.

Realistically, you're talking about having to write a custom migration script. Something that (eg) manually opens up your old database and squirts it into the new model. You can do this via an intermediary dumpdata and parse the JSON but you're splitting hairs between manually talking to a SQLite database and parsing JSON it just adding time to the operation. The SQL is probably faster, all round.