You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Defining tasks solely in the Config file's init() method requires a single entry point for all scheduling. It might be good to offer a way to extend this to libraries and modules, so (for example) an Auth library could "register" its own tasks for periodic cleanup of spam accounts.
The text was updated successfully, but these errors were encountered:
I'm not opposed to this, but this would also require a new command to be able to list what all is registered so there's no surprises by installed packages.
One thing nice about the single entry point is that you always know what is scheduled.
Another point to be made is resolving multiple Task configs. For example, right now a developer could create app/Config/Tasks.php with init() to supply their own task specs. But, some package could also create Foo\Bar\Config\Tasks which might get loaded by config('Tasks') before this one. Having a modular way to schedule tasks prevents accidental overlaps.
Defining tasks solely in the Config file's
init()
method requires a single entry point for all scheduling. It might be good to offer a way to extend this to libraries and modules, so (for example) an Auth library could "register" its own tasks for periodic cleanup of spam accounts.The text was updated successfully, but these errors were encountered: