Am 12.07.2016 um 12:25 schrieb Jaime Crespo:
Your last question is a non issue for me- I do not
care if things are
on the database or on configuration- that is not the issue I have been
complaining about.
Yea, still something we need to figure out :)
I'm fine with the DB based solution, if we have decent tooling for extensions to
register their content models, etc.
What I blocked is having 6000 million rows (x40 due to
redundancy)
with the same column value "gzip; version 3 (1-2-3-testing-testing. It
seems to work)" when it can be summarized as a 1-byte or less id (and
that id be explained somewhere else).
Yea, that's not what I would recommend either. What I meant is that we can now,
as a stepping stone and without blocking on a schema change, fill in the null
values in the revision table for the revisions of a page that is being converted
to a new model, to avoid confusion. Converting pages to a different model is
relatively rare, so I think it would not have much of an impact on the big picture.
Of course there are a lot of history and legacy and
maintenance
issues, but when the guy that actually would spend days of his life
running schema changes so they do not affect production is the one
begging for them to happen you know there is an issue. And this is not
a "mediawiki" is bad complain- I think mediawiki is a very good piece
of software- I only want to make it better with very, very small
maintenance-like changes.
I'm all for it!
The disadvantage is of course that the model and
format are not obvious when
eyeballing the result of an SQL query.
Are you serious? Because this is super-clear already :-P:
That was, if I remember correctly, one of the arguments for using readable
strings there, instead of int values and a config variable, as I originally
proposed. This was discussed at the last Berlin hackathon, must have been 2012.
Tim may remember more details. We should probably re-consider the pros and cons
we discussed back then when planning to change the scham now.
-- daniel