what is the issue with database changes?

[Jan Heylen]

On Fri, Mar 20, 2015 at 5:28 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> 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


So, are you saying that runtime detecting changes to the database
(create a table that doesn't exist) is not possible? And if that is
not what you are saying, has it ever been done? And if not, can you
describe a way to do that in model python code of kallithea?

I'm just looking for the best way to introduce a new feature (and
therefore I would need a extra "comment type"), without trying to
write a new clean database scheme now.

The other solution is that I somehow hide the type in one of the
fields already available, but that is even uglier than all other
options I believe.

Jan