Member Since 4 Years Ago
1,750 experience to go until the next level!
In case you were wondering, you earn Laracasts experience when you:
Earned once you have completed your first Laracasts lesson.
Earned once you have earned your first 1000 experience points.
Earned when you have been with Laracasts for 1 year.
Earned when you have been with Laracasts for 2 years.
Earned when you have been with Laracasts for 3 years.
Earned when you have been with Laracasts for 4 years.
Earned when you have been with Laracasts for 5 years.
Earned when at least one Laracasts series has been fully completed.
Earned after your first post on the Laracasts forum.
Earned once 100 Laracasts lessons have been completed.
Earned once you receive your first "Best Reply" award on the Laracasts forum.
Earned if you are a paying Laracasts subscriber.
Earned if you have a lifetime subscription to Laracasts.
Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.
Earned once you have achieved 500 forum replies.
Earned once your experience points passes 100,000.
Earned once your experience points hits 10,000.
Earned once 1000 Laracasts lessons have been completed.
Earned once your "Best Reply" award count is 100 or more.
Earned once your experience points passes 1 million.
Earned once your experience points ranks in the top 50 of all Laracasts users.
It looks like it is the destructor that does the actual despatching, see:
It's an interesting concept, a class that does not do anything until it goes out of scope. But it makes perfect sense. So
dispatch() does not actually dispatch a job, but it creates a job pending dispatch, and you can keep tweaking it until it is destroyed.
The more you understand, the more you can make Laravel bend to your will. Love it :-)
Replied to Database Transaction Or Query->save() ?
Note that the return value of
save() is not success/fail. It simply tells you whether the database was updated or not. It may not be updated if there is nothing changed in your model, which can't really be described as a fail. However, you may have pre-save validation checks that can prevent saving, and those could be considered a fail. Just use with caution.
Note that I can either add the options to the job, then dispatch that when all the options are set up. That makes sense to me if the
dispatch() function "does the deed".
But dispatching the job then adding the options also works, and that is how it is documented in most of the Laravel docs. That makes no sense to me, unless something is happening under the bonnet that I'm not aware of. I guess the destructor of the queue object could do it - as soon as the dispatched job object is out of scope, it will be cleaned up by PHP, and it could throw itself onto a queue as its last desperate act. Is that how it works?
Started a new Conversation Job Dispatch Options - How Does This Actually Work?
This is something I am trying to wrap my head around, and I'm sure I am simply missing something really simple.
I can dispatch a job like this:
That dispatches to the default connector and queue (assuming the job itself does not fiddle with those details).
I can also add some options:
So, each option that is added, returns either a new object or updates the queue object. That makes sense.
What I don't understand, is at what point the job actually gets queued. There is no final "do it now" method like there is for eloquent (e.g.
->get()). So when does the music stop with this one? How do I actually get to keep adding options before the job finally ends up on the queue. What puts it onto the queue - is it the destructor of the app maybe? Puzzled.
Hmm, just found the problem. It actually WAS all working, but the tool I was using to view the log entries that were being sent to elk, was stripping out all the JSON. Doh.
Started a new Conversation Logs Not Formatted As JSON When Run From A Container
This is a strange one I can't wrap my head around.
We have a php-fpm container that runs lumen. php-fpm is set to catch
stderr from the PHP workers and send it to the container
/proc/1/fd/2) and that works.
Now I have set up a logging channel to format all log entries as JSON and send them to
stderr for the PHP worker). The log channel looks like this:
use Monolog\Handler\StreamHandler; 'stderr-json' => [ 'driver' => 'monolog', 'handler' => StreamHandler::class, 'with' => [ 'stream' => 'php://stderr', ], 'formatter' => Monolog\Formatter\JsonFormatter::class, ],
Running a PHP artisan command from a shell in the container to log an error, I can see the full error details being returned to my shell as formatted JSON. That works well too.
But when the nginx container runs a
php-fpm worker in the
php-fpm container, the logs it gets are not formatted at all - just the plain log text message.
What could be happening?
Commented on Reduce A Query From 12 Seconds To 1 Millisecond
It's not about year(). The point is that ANY function that is used in a where clause will be executed for every single matching row that needs to be checked, whether that row is in the final result or not.
Replied to Laravel Cache (where Expiry Time Is Set?)
Old, old thread, but just for anyone coming across it - cache times from Laravel 5.8 is specified in seconds. This is to fall in line with other libraries and PSRs.