On Fri, Mar 20, 2015 at 5:28 PM, Mads Kiilerich <[email protected]> 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 _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
