what is the issue with database changes?

[Mads Kiilerich]

I think Matt's response in this thread gives a good answer to "why not" 
and is a relevant challenge but doesn't give a "good" answer to "then 
how". It would be nice if the described ideal was feasible ... but I 
don't think it is for us. Scaleable nosql databases lean more towards 
that - the old-fashioned sql+orm LAMP-ish stack with legacy code: not so 
much. On-the-fly migration and "(implicit) record versioning" is not 
feasible with our current sql+orm stack.

The inherited database scheme in Kallithea _is_ fundamentally broken. 
There is no way we can "support" all previous schemes and invariants at 
once. Our only option is to establish a new clean data model and migrate 
all systems to the new invariants. The more stable we can keep it, the 
better. But I think the most stable solution often will be to change the 
database model.

I think the Kallithea database scheme is more like an internal API 
(which for good reasons is "unstable" in Mercurial ... and which cause 
some pain for projects like Kallithea who doesn't follow the official 
guideline for how to deal with that) and not so much like a on-disk 
format (which is quite stable in Mercurial).

Fortunately, compared to Mercurial, a Kallithea system only has one 
instance of the software accessing and encapsulation the database. 
(Interoperability with legacy systems and upgrades will probably be 
removed with after 0.2) Kallithea also has the existing system in place 
for upgrading/migrating the database content and scheme.

/Mads