what is the issue with database changes?

[Mads Kiilerich]

On 03/20/2015 05:44 PM, Jan Heylen wrote:
> 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?

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