r94809 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:< r94808‎ | r94809 | r94810 >
Date:20:09, 17 August 2011
Author:khorn
Status:resolved (Comments)
Tags:
Comment:
r94720 r94771
Uncomments the 'LoadExtensionSchemaUpdates' hook in ContributionTracking.
Modified paths:
  • /trunk/extensions/ContributionTracking/ContributionTracking.php (modified) (history)

Diff [purge]

Index: trunk/extensions/ContributionTracking/ContributionTracking.php
——@@ -35,7 +35,7 @@
3636 $wgAutoloadClasses['ContributionTrackingProcessor'] = $dir . 'ContributionTracking.processor.php';
3737
3838 //this only works if contribution tracking is inside a mediawiki DB, which typically it isn't.
39 -//$wgHooks['LoadExtensionSchemaUpdates'][] = 'efContributionTrackingLoadUpdates';
 39+$wgHooks['LoadExtensionSchemaUpdates'][] = 'efContributionTrackingLoadUpdates';
4040
4141 // Resource modules
4242 $ctResourceTemplate = array(

Follow-up revisions

RevisionCommit summaryAuthorDate
r95254r94809: This will now use the updater object for schema changes only if the e...khorn21:12, 22 August 2011

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r94720In the process of adding an API to ContributionTracking, I ended up refactori...khorn00:58, 17 August 2011
r94771Switch ContributionTracking to use newer updaterreedy16:33, 17 August 2011

Comments

#Comment by Awjrichards (talk | contribs)   00:43, 18 August 2011 
//this only works if contribution tracking is inside a mediawiki DB, which typically it isn't.

I suspect this can be mitigated by connecting to the correct database - the variables for the database that *should* hold the contribution_tracking tables get set on lines 58-61 of this revision and are configurable in LocalSettings.php.

According to Reedy, you should be able to create a new $updater instance and pass it an appropriate $db object. Perhaps you could do something like: 

if ( $wgContributionTrackingDBserver != $wgDBserver ) {
  // create db object with $wgContributionTrackingDBserver data
  // create new $updater object with the new $db object
  // run the schema updates/installs/whatever
} else {
  // use the updater normally
}

#Comment by Khorn (WMF) (talk | contribs)   19:05, 18 August 2011

Ha! Er, sort of...

Using this technique, I am able to get it to populate the correct database. However, the tables from ALL my loaded extensions are also created in my ContributionTracking Database. DatabaseUpdater's constructor does this before it's done: 

wfRunHooks( 'LoadExtensionSchemaUpdates', array( $this ) );

Makes sense to call the first time...

If I can conditionally NOT do that when constructing my local DatabseUpdater, though, everything seems to work as expected. Suggestions?

#Comment by Khorn (WMF) (talk | contribs)   21:24, 22 August 2011

So, after talking about it, we decided it would be best to just do the updates manually if the tables live in a different database. Please let me know if there's anything else I need to be doing in the manual update section. I have tested this locally and it appears to work both ways, in various states of tables and columns not existing.

#Comment by Bryan (talk | contribs)   21:53, 19 August 2011

If the appropriate LBFactory is configured, you can just pass $wgContributionTrackingDBServer to wfGetDb().

Status & tagging log