![]() For example, the package provides a simple and elegant way to log model changes. There are a number of third-party packages that can help you log changes to database tables in Laravel. If you do decide to use database triggers, be sure to write them carefully and test them thoroughly. ![]() Use Laravel model events for logging changes to database tables in Laravel applications, unless performance is a critical concern. Here is a summary of the key differences between database triggers and Laravel model events for logging: Database Triggers vs Laravel Model Events Features By listening to these events, we can perform specific operations at specific stages of the Eloquent model instance life cycle. ![]() However, if performance is a critical concern, you may want to consider using database triggers instead. There are a few different ways you can do this, and in this tutorial, I will walk through them and explain the benefits and drawbacks of each one. They are simpler to write and maintain, and they are easier to test. Published on August 25th, 2022 by Steve McDougall When working with Eloquent Models, it is common to tap into the events dispatched through the Models lifecycle. In general, I recommend using Laravel model events for logging changes to database tables in Laravel applications. Portability: Laravel model events are less portable than database triggers because they are specific to Laravel. Performance: Laravel model events are generally slower than database triggers because they are executed by your Laravel application. Testable: Laravel model events are easier to test than database triggers because they can be tested inside of your Laravel application. Simple: Laravel model events are simpler to write and maintain than database triggers. Portability: Database triggers are more portable than Laravel model events because they are not specific to Laravel.Ĭomplexity: Database triggers can be complex to write and maintain.ĭebugging: Database triggers can be difficult to debug because they are executed outside of your Laravel application. Performance: Database triggers are generally faster than Laravel model events because they are executed directly by the database engine. Laravel model events: Laravel model events are a Laravel-specific feature that allows you to listen for and respond to changes to Eloquent models.īoth approaches have their own advantages and disadvantages. $taggablePivot->submitted_by_id = $user ? $user->id : 0 ĭoing this prevented me from having to spend time doing a potentially risky refactor of a lot of untested code, and helped to save a lot of time.There are two main ways to log changes to database tables in Laravel applications:ĭatabase triggers: Database triggers are special procedures that are automatically executed when certain events occur on a table, such as INSERT, UPDATE, or DELETE. Return $this->morphToMany(Tag::class, 'taggable') You need make sure that your pivot table model is either extending Illuminate\Database\Eloquent\Relations\MorphPivot or Illuminate\Database\Eloquent\Relations\Pivot. This will allow Laravel to start firing off these events, and for us to start listening for them. It turns out, there is a method called using that lets you define a model for your pivot table to use on the relationship. The problem is that Laravel doesn’t fire off events on a pivot table. This way existing tags won’t get updated, but newly created tags will have the propper submitted_by_id. One way around this is to listen for the events that eloquent fires off (creating, created, updating, updated, etc), specifically the creating event, and use that to set the submitted_by_id to the authenticated users id. In order to acheive this I would have to get all the current tags, and preform some kind of logic ahead of time to decide who the submitted_by_id should actually be before syncing.Īnother problem is that this tags()->sync() functionality was happening all over a code base that has no test coverage causing the refactoring process to be somewhat risky. ![]() We wanted to maintain the data of who first attached the tag to the post. ‘2’ => ,īut the problem this would create is that any existing tag would have it’s submitted_by_id changed to the new users id. One way I could of handled it was to provide an associative array where the key was the tag id and the value was an array of attributes to store on the pivot table. Most of the code was setup to do something like: It wasn’t working properly and they asked me to fix it. However on the taggables table, they had a submitted_by_id field that they wanted to contain the id of the user who attached the tag. The company was using a polymoprhic pivot table called taggables to manage the relationship between a tag and any one of a number of different models. I was recently tasked with solving an interesting problem for one of my contract clients on their Laravel app. Glenn Listen for events fired from pivot tables in Laravel ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |