Extending models in Eloquent

Caleb Porzio, co-presenter of the Twenty Percent Time podcast, published a new article on the Tightenco blog. This time he guides us through a nice use case for extending Eloquent models.
Let’s explore another alternative that can be used as a stand-in for repetitive where statements and local scopes. This technique involves creating new Eloquent models that extend other models. By extending another model, you inherit the full functionality of the parent model, while retaining the ability to add custom methods, scopes, event listeners, etc. This is commonly referred to as “Single Table Inheritance,” but I prefer to just call it “Model Inheritance”.

A Laravel package to rebuild the database

Out of the box Laravel comes with a few commands to migrate the database. One of them is migrate:refresh. That one will first run the down-steps for all your migrations and then run all the up steps. After that process your database should have the same structure as specified in your migrations. But what if your migrations don't have a down-step? Because I seldom have to revert a migration in my recent projects I haven't bothered with coding up the down steps. And without those down steps running migrate:refresh will result in errors, or worse, tears. I've created a little package that contains a command to quickly nuke all the tables in the database, run all migrations and all seeders. It will not use the down steps of the migrations but will simple use the output of the SHOW TABLES query to knock down all tables. Once the package is installed this is how you can build up your database again:
php artisan migrate:fresh
Need to run the seeds as well? No problem!
php artisan migrate:fresh --seed
The package works on MySQL, PostgreSQL and SQLite databases. If you need to perform some extra steps right before or right after the tables are dropped, you can hook into these events. This this all sound good to you? Then check out the package on GitHub. On our company site you'll find a list of Laravel packages we've previously made.

How is Doctrine 2 different to Eloquent?

One of the really great things about ORM’s that implement the Active Recordpattern like Eloquent is, they are really easy and really intuitive to use. With Active Record, you basically just have an object that you can manipulate and then save. Calling save() on the object updates the database, and all of the magic persistence happens behind the scenes. Having the business logic of the object and the persistence logic of the database tied together definitely makes working with an Active Record ORM easier to pick up. In this tutorial I want to explore exactly how Doctrine 2, an ORM that implements the Data Mapper pattern, is different to Eloquent.