Using Laravel 10, I don't have the 'ShouldHandleEventsAfterCommit' class under "Illuminate\Contracts\Events" directory, so IDE is throwing an 'Undefined type' error. Any clues? Has anyone run into this?
Hello and thank you for your videos. I have a similar case of an observer being triggered inside of a DB transaction. The bug is that the observer triggers twice. Do you think this is related to what you are talking about? Thank you for your time
I guess because, in some scenarios, maybe you actually want your observer to be fired as soon as possible, even if the transaction should fail (e.g. the observer writes something to a log - although I wouldn't use an observer for such a scenario)
That's why I love Laravel framework. Very simple and efficient 😄
I'm a big fan of Observers, so thank you very much for the tip !
Using Laravel 10, I don't have the 'ShouldHandleEventsAfterCommit' class under "Illuminate\Contracts\Events" directory, so IDE is throwing an 'Undefined type' error. Any clues? Has anyone run into this?
Great Tip, Thank you 👏
thanks for the nice information
Never knew about that handy Interface, cool video. 👍
Great tip!
Hello and thank you for your videos. I have a similar case of an observer being triggered inside of a DB transaction. The bug is that the observer triggers twice. Do you think this is related to what you are talking about? Thank you for your time
Can't answer without debugging the code, sorry
so what's the difference about that and ShouldDispatchAfterCommit? I dont understand.
That one is for jobs, not observers
souunds like ShouldHavndleAfterCommit should be implemented by default
Wow! Didn't know that! Probably this is gonna save me in the future...
Can we use ShouldHandleEventsAfterComit in traits such as ActivityLogger trait?
I don't think that would work. But I haven't tried.
When used with Filament panel's databaseTransactions(), the Observer events are not fired. Can you confirm this?
Not sure which observer exactly, on which model. Without debugging the actual code, can't answer.
after implementing this do we need to implement db transactions everywhere to trigger the observer??
No, it's your personal choice whether to use transactions. Search my channel for other videos about transactions.
Just curious: I wonder why this isn’t enabled by default, any clue?
Because DB transaction is not apply by default
I guess because, in some scenarios, maybe you actually want your observer to be fired as soon as possible, even if the transaction should fail (e.g. the observer writes something to a log - although I wouldn't use an observer for such a scenario)
@@eleftrik Where would you write to a log then?
@@ilyasavenok9051 It depends. Generally speaking, immediately after data has changed, without using observers or events.
But what about this option "after_commit" in the config file?
That one is for queue jobs, not observers
It's crucial to test both successful cases and scenarios where transactions fail to ensure specific jobs are not pushed.
Very helpful tip, thanks alot.
Really good! Thanks for this!
Just what I needed. Very timely. 😁
Thank you very much 💛
Log viewer is a package? I need it. 😮