what is the issue with database changes?

[Jan Heylen]

On Tue, Mar 3, 2015 at 7:55 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2015-03-03 at 15:24 +0100, Thomas De Schampheleire wrote:
>> Hi,
>>
>> Regularly I hear that we don't want to change the model yet to stay
>> backwards compatible.
>>
>> However, I do see several 'dbmigrate' scripts in the source base,
>> which hint at it being possible to migrate across database changes.
>>
>> Can someone explain in more detail why we do not want such database
>> changes (yet)?
>
> On-disk format migrations are an anti-pattern of software development.
> They're fragile and one-way and present a large barrier to user
> acceptance of new versions. And there's no excuse for them when you have
> a database rather than a file format: you can always add new tables
> without changing the structure of the existing tables.

So, given this anti-pattern, say you want to introduce a new type of
changeset-comment, I see 3 options:

1. add a new Column in the ChangesetComment class, nullable, and
foresee a default when null.

If I got it right, database-model-wise downgrading shouldn't be an
issue, the column is just ignored, but all the comments are seen as
the normal comment type, which is unwanted in some cases.

2. add a new Class (so database table) e.g. ChangesetCommentType, with
an extra field to indicate type, and load both tables when querying
data (sounds ugly)

But when downgrading, all the data stored in that table is not seen,
so all "new" comments are lost.

3. add a new class (so database table) e.g. ChangesetOtherCommentType,
and only use it for 'the other type' and keep using ChangsetComment
for comments and use the other table for the new feature.

No issue with downgrading. The new table is just not seen by the old model.

Or is downgrade-ability not a requirement?

For all three, I also have the question: Is there a migrate (script)
needed? And how does that work, for as far as I can see, the 'old'
model db.py is copied to another class, and the new db.py get an
increased version number. Or how should somebody who upgrades, get the
database updated without losing all his data?

And this migrate, does one needs to do that manually or is it
automatically detected when launching kallithea server with the
changed database model?

br,

Jan

>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
> _______________________________________________
> kallithea-general mailing list
> kallithea-general at sfconservancy.org
> http://lists.sfconservancy.org/mailman/listinfo/kallithea-general