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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
