On 03/20/2015 05:44 PM, Jan Heylen wrote:
On Fri, Mar 20, 2015 at 5:28 PM, Mads Kiilerich <m...@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?
No. But I doubt it is easy and I doubt it will give a good result.
You could try to implement it. I guess it would imply significant
changes to how we use sqlalchemy and "models".
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?
[moot]
I'm just looking for the best way to introduce a new feature (and
therefore I would need a extra "comment type"),
I suggest doing that with a migration step, as the code shows has been
done many times before. The SSH PR seems to do the same - I haven't
reviewed/tested in detail.
without trying to write a new clean database scheme now.
I don't know what "new" and "clean" means here and why you want to avoid it.
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.
Yes.
/Mads
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
