Chad wrote:
I think we should probably work on mediawiki.org (subpage of RfC?). This is something that needs to be thought out properly, and I think on-wiki would be more productive than on-list.
Okay. I will create an RFC page. Keep in mind that my time is limited and I've only just started to write the proof of concept for it, so please don't hold up version 12.0 to wait for me, ha ha ha!
Platonides wrote:
It took me a while to remember that idea of replacing the sql files with an abstract schema.
Right. I've been thinking about this a lot, and the big picture plan is to remove all the tables.sql files and create a single text file, mediawiki.schema, which will have a generic schema, very similar to the existing main tables.sql, but with a stricter syntax and more generic definitions. This will be parsed and put into a php structure. Each database will walk through this structure to build it's own 'create' statements, using common methods and attributes whenever possible. Similarly, we can use this for updates as well by simply walking through and adding missing tables, rather than having to create patch files or other shenanigans. Most of the above is written: the tricky part is actually figuring out exactly what the intent of each column definition in the current tables.sql is! There is a lack of consistency and some questionable choices. This will also be a great time to introduce some standards, e.g. naming of indexes.
Krinkle wrote:
I'd say put it in Gerrit from the start (in a branch) so that everyone can check it out and send suggestions (either as a commit or through the feedback channels on the mailing list, wiki or Gerrit comments).
Gerrit reviews are also enabled for branches, so you don't have to worry much about clashing with others, a commit to the branch on gerrit will not end up in the actual branch until it is reviewed.
I don't think this is a good idea: the having to wait for a reviewer before your changes show up elsewhere is great for the core code, but not so great for fast-n-furious early prototyping of a big feature. Perhaps we can add it to gerrit once everyone thinks we have a mostly stable prototype?
Thanks for all the feedback. I will post here when I add a branch and/or create an RFC page.
On Fri, Apr 20, 2012 at 5:27 PM, Greg Sabino Mullane greg@endpoint.com wrote:
Krinkle wrote:
I'd say put it in Gerrit from the start (in a branch) so that everyone can check it out and send suggestions (either as a commit or through the feedback channels on the mailing list, wiki or Gerrit comments).
Gerrit reviews are also enabled for branches, so you don't have to worry much about clashing with others, a commit to the branch on gerrit will not end up in the actual branch until it is reviewed.
I don't think this is a good idea: the having to wait for a reviewer before your changes show up elsewhere is great for the core code, but not so great for fast-n-furious early prototyping of a big feature. Perhaps we can add it to gerrit once everyone thinks we have a mostly stable prototype?
We can enable direct pushing on branches as well, that's not a big deal :)
-Chad
On 20/04/12 23:27, Greg Sabino Mullane wrote:
Right. I've been thinking about this a lot, and the big picture plan is to remove all the tables.sql files and create a single text file, mediawiki.schema, which will have a generic schema, very similar to the existing main tables.sql, but with a stricter syntax and more generic definitions. This will be parsed and put into a php structure. Each database will walk through this structure to build it's own 'create' statements, using common methods and attributes whenever possible. Similarly, we can use this for updates as well by simply walking through and adding missing tables, rather than having to create patch files or other shenanigans. Most of the above is written: the tricky part is actually figuring out exactly what the intent of each column definition in the current tables.sql is! There is a lack of consistency and some questionable choices. This will also be a great time to introduce some standards, e.g. naming of indexes.
Note we will also need a way to generate a SQL from that (eg. for manually creating a new database with SQLAdmin).
Personally, I prefer viewing the code (SQL) which is really used, but I won't stop you from making the perfect abstraction.
wikitech-l@lists.wikimedia.org