fuel-dev team mailing list archive

[Nikolay Markov <nmarkov@xxxxxxxxxxxx>]

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