Last modified: 2008-04-05 09:19:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9302, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7302 - JobQueue should allow custom job types
JobQueue should allow custom job types
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-13 02:38 UTC by Gregory Szorc
Modified: 2008-04-05 09:19 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Skeleton class for custom jobs (789 bytes, text/plain)
2007-05-17 23:38 UTC, Daniel M. Herzig
Details
modified factory method to enable the jobqueue for custom jobs (1017 bytes, text/plain)
2007-05-17 23:39 UTC, Daniel M. Herzig
Details

Description Gregory Szorc 2006-09-13 02:38:45 UTC
The job queue should be able to accept any type of job command, not be limited
to internally-defined commands.  This is necessary because some extensions may
need to modify many articles or perform additional time-consuming activities
after an edit is performed.

There are two issues that need be resolved

1) The ability to define a custom job to run
2) The ability to run a defined custom job

The solution to #1 could be done utilizing the ArticleSave hook.  However, it
might be easier if a new hook was introduced in Article::editUpdates().  (It is
worth noting that the ArticleEditUpdatesDeleteFromRecentchanges hook could be
used for this, but that hook's description has nothing to do with what we are
trying to accomplish).

There are two solutions to #2.  Both involve modifying JobQueue::factory() so
the default: case in the switch block attempts to call a user-defined function.

1) Use a hook to obtain an instance of the Job class suitable to handle a
specified command.  This means creating a skeleton job class and passing it to
the hook and testing to see if the object was re-casted as a different object
type by any hooks that were run.

2) Rely on the __autoload functionality to try to instantiate an instance of a
class named 'Job_$command' or something similar.

#2 is probably the preferred way to do this, at least from an object-oriented
standpoint.
Comment 1 Daniel M. Herzig 2007-05-17 23:38:16 UTC
Created attachment 3648 [details]
Skeleton class for custom jobs
Comment 2 Daniel M. Herzig 2007-05-17 23:39:06 UTC
Created attachment 3649 [details]
modified factory method to enable the jobqueue for custom jobs
Comment 3 Daniel M. Herzig 2007-05-17 23:40:20 UTC
(In reply to comment #0)

I absolutely agree with Gregory that there is a need for custom jobs and I think the second option (autoload) is a good mechanism to enable the JobQueue to handle them.

Find my suggestion for the JobQueue::factory() method in the attached file (factory.txt).
Basically, it uses Autoloader::__autoload($classname) to get the class.

The only thing one has to keep in mind is that the $command has to match the job's classname from now on.

I wrote several custom jobs and it worked fine for me.
For the sake of completeness I attached the DummyJob class (DummyJob.txt).


Comment 4 Alexandre Emsenhuber [IAlex] 2008-04-05 09:19:39 UTC
I think this should be fixed with $wgJobClasses, added in 1.11. For example, renameuser extension use a job to update revisions to the new user name. Marking bug as resolved.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links