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