Correct work flow between Tasks/Jobs/Notifications
I've created a notification that needs to fire when an expiration date is less than 7 days away.
My question is, is it a bit redundant to create a Scheduled task to check every #hrs that then calls a job to check the dates that then calls the notification.
Or is the more preferred workflow Scheduled task calls a controller function to check the dates, which if it matches the criteria calls the notification.
Most of the time doing the query in the scheduled command is all you need. If there are any records found you can send the notification as you're iterating over the results.
However, if you are querying millions of records, it would probably be ideal to separate this into a few jobs where you could chunk the results into jobs, then each job handles the notification call. There are a number of ways to accomplish this though.
Sorry if that wasn't clear. No, you should definitely not do a foreach in the Kernal file. The kernal would reference a command, then in the command you'd have your foreach.
So when you say 'command', should I be creating my own artisan command that runs the foreach loop which in turn creates a job for each iteration of the foreach loop?
Or whats the best fit for the middle ground where:
Kernel runs a scheduled task ----> ?? ----> Job for each iterated object
So when you say 'command', should I be creating my own artisan command that runs the foreach loop which in turn creates a job for each iteration of the foreach loop?
yes, exactly. You could also send the notification inside of the foreach instead of referencing another job to keep it simpler. If you'd like to do more than just send the notification, you should reference another job (in my opinion)