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
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
