Am 12.07.2016 um 18:00 schrieb Rob Lanphier:
On Tue, Jul 12, 2016 at 1:40 AM, Daniel Kinzler <daniel.kinzler@wikimedia.de
The original design of ContentHandler used integer IDs for content models and formats in the DB. A mapping to human readable names is only needed for logging and error messages anyway.
This oversimplifies things greatly. Integer IDs need to be mapped to some well-specified, non-local (global?) identifier for many many purposes (reading exports, writing exports, reading site content, displaying site content for many contexts, etc)
Yea, sorry. That we only need this for logging is what I assumed back then. Not exposing the numeric ID at all, and using the canonical name in dumps, the API, etc, avoids a lot of trouble (but doesn't come free).
We need to put a lot of thought into content model management generally. This statement implies managing content models outside of the database is easy.
Well, it's the same as namespaces: they are easy to set up, but also too easy to change, so it's easy to create a mess...
As explained in my earlier response, I now realized that content models differ from namespaces in that they are not really configured by people, but rather registered by extensions. That makes it a lot less awkward to have them in the database. We still have to agree on a good trigger for the registration, but it doesn't seem to be a tricky issue.
What we still need to figure out is how to solve the chicken-and-egg situation with Multi-Content-Rev. At the moment, I'm thinking this might work:
* introduce content model (and format) registry in the DB, and populate it. * leave page and revision table as they are for now. * introduce slots table, use the new content_model (and content_format) table. * stop using the content model (and format) from the page and revision tables * drop the content model (and format) from the page and revision tables
Does that sound liek a good plan? Let's for a moment assume we can get slots fully rolled out by the end of the year.