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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7302 - JobQueue should allow custom job types
JobQueue should allow custom job types
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  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: ---

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

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
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.