Hello colleagues, Right now we already have working DB migration mechanism presented by Alembic, but it becomes more and more complex as we move towards upgrades.
First, as we agreed, migration from previous version of Fuel DB to the next one will be presented by a single file. The question is, do we need to keep it single during development process or we shouls just merge all the files into one migration just before release? To clarify things, it's not really possible to generate completely working migration from the scratch taking the diff between two releases, because there are some issues in auto-generated scripts which may be fixed by hands only during development. And our single migration script (current.py) is becoming more and more huge as we don't keep small updates in a separate files. As for me, I don't see any issues with keeping multiple migrations in code repo (that's the common practice of majority of projects). Please write your objections. Second, it's not clear right now how we're going to achieve backward compatibility. We will have separate versions of almost all objects in code and will select corresponding ones by Environment versions. The thing is, it will be very hard for us to write working migrations in both directions without serious data loss, especially if we'll have lots of changes in DB schema. I proposed to use separate DB for each major API version (which may have completely independent schemas) and just write data migration scripts (v1->v2 and v2->v1), for example, to allow adding nodes to v1 cluster. This seems as a huge overhead, but actually helps to get away of bad headache writing DB migrations. Please let's discuss all these things it this thread. -- Best regards, Nick Markov -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
