t
strings vs integers is not something I'm too worried about. A varchar(16) is essentially 128 bits and with all the things a DB has to do i'm not too worried about comparing a 32bit int vs a 128bit string. I do feel that adding yet another field to compare to is just adding to the complexity of the existing solution while not having a great benefit. After some discussion with the team we have come up with another possible solution(which is much more work, but perhaps worthwhile in the long run). We are proposing to deprecate the existing rc_type field in the recentchanges table in favor of a new string field rc_source. We would modify the existing core (and extension as necessary) code to start inserting into this new field. Grep's through mediawiki and its extensions suggest there are only a handful of places that would need to be transitioned, some work but not impossible. DB changes: ALTER TABLE recentchanges ADD rc_source varchar(16) binary not null; Changes to constants used: RC_NEW becomes RC_SRC_NEW RC_EDIT becomes RC_SRC_EDIT etc. define( 'RC_SRC_NEW', 'mw.new' ); define( 'RC_SRC_EDIT', 'mw.edit' ); etc. Extensions can create their own constants which avoid most coordination that the previous proposal would have needed: define ( 'RC_SRC_FLOW', 'flow.something' ); I'm not certain if the db servers would like us going back through time and updating all the recentchanges rows on the various wiki's, most prudent would be for us to get all the insertion points populating the new tables and wait a month for all the old data to be deleted from recentchanges. At that point we will mark the existing uses of rc_type as deprecated and start transitioning queries to the new field. I have not previously done this sort of transition in core so no comment yet on how long we would be populating both fields in the database. Is this approach more reasonable? Caveats? Erik Bernhardson On Thu, Sep 19, 2013 at 5:49 PM, Daniel Friesen <dan...@nadir-seen-fire.com>wrote: > You can trivially avoid the need to do anything as complex as dynamic > namespace registration by simply using one of your other options like > using the string 'wikidata' or 'flow' rather than a constant and integer > id. > If you want integer ids that badly you could always create a new > rc_external_types (or whatever you want to call it) mapping an > auto_increment id to keys like 'wikidata' and 'flow' and use the primary > key there as the rc_external_type. > > Long story short. Hardcoding integer numbers into extensions hoping > you're not going to conflict with other extensions is never a good idea. > You're just subjecting yourself to future pain you could have avoided at > the start with a simple solution. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] > > On 2013-09-19 5:41 PM, Erik Bernhardson wrote: > > I will take a look over the bug, quite a long conversation. It will take > > me the night most likely to digest the suggestions included. I suppose > my > > first worry is that I was targeting simple changes which can be agree'd > on > > and implemented in a few lines, whereas the linked bug report seems to > > suggest a system that I know will require many iterations and weeks of > > on/off work before +2'd into core. > > > > Erik Bernhardson > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
