Task Scheduling work from database

[MgHtinLynn]

Task Scheduling with database as queue jobs with database jobs and fail jobs option with default(current) and database That will be smarter than current Task Scheduling.

[Patryk27]

Hi,

It's quite hard to understand what you mean - could you please try explaining your idea again?

[MgHtinLynn]

Dynamic Task Scheduling with database driver options seem like logic flow to queue jobs with database driver jobs table and fail jobs table.Current Task Scheduling is like default and static and user UI request action can't access to cron jobs (Task Scheduling). That whys my points is only update to Task Scheduling Table and Task Scheduling Table will run depend with database. I thought that will be smarter than current task scheduling. @Patryk27

[thannaske]

Ok I think I got what he want: Dynamic Task Scheduling must be hard-coded at the moment. You need to put something like this in your code $schedule->job(new Heartbeat)->everyFiveMinutes(); to achieve that the server-side cronjob that is executed every minute will execute the task.

@MgHtinLynn would like to see a feature that you are able to define those scheduled recurring tasks in a database. This would have the big advantage that changing, disabling, adding or deleting those recurring tasks does not lead into a code-change.

Good idea, indeed.

[Garbee]

If that's what you want, you can build it now in user-land exactly how you need it for your application. There is no need for this to be in the Laravel internals.

[thannaske]

If that's what you want, you can build it now in user-land exactly how you need it for your application.

Same applies for Job Queue, Localization, E-Mail Validation and every other feature the framework offers. So in my opinion that is not an argument for not thinking about a dedicated out-of-the-box solution for this idea.

[Garbee]

Your opinion is perfectly valid. However, the extra complexity this brings on is a problem. First off, there needs to be a normalized way of handling the details for configuring a task that works across all kinds of use-cases, or at least as many as possible. This isn't easy on its own. Then, you need to make sure nothing breaks in upgrading versions. So any API changes need to be handled very smoothly. Something Laravel is notorious about getting wrong by just breaking things whenever. My point isn't about opinions, it's about logistics. Logically, this isn't something Laravel should be doing. The surface area for breaking things on upgrades increases without providing much real benefit.

Where is the beneficial use-case here? If you're app intends to make cron jobs from the database, then your app should know how to do that. Otherwise, it should be checked into version control.