I’ve recently started to play around with Laravel, and so far I absolutely love it! You can get up and running super fast, and the Eloquent modelling system lives up to its name.
One thing I did find tricky though, is keeping a handle on the make-up of my models — and although I’ve only started, it occurred to me that the maintainability of my models was going to be an issue.
First, let’s talk briefly about how Laravel handles the creation of a model. There are essentially two components; the model class itself, and a corresponding database table. The model class is easy, and thanks to Laravel’s ‘migrations’ concept — so too is getting the database table in place.
Migrations are fantastic for incrementally changing the model as the project develops over time, making it really easy, and safe, both to deploy changes to production, and to get the project checked out and up and running — even if it has changed significantly since you last worked on it. Migrations move the database forward in incremental steps, and it’s pretty painless.
But because of the incremental nature of these migrations, there is, by definition, no one place where you can examine all of the properties of the model. In the model class, only those properties that have magic getters, or are part of a relationship, will really have any code against them. So there’s no automatic definition of the model inside the class; all of Eloquent’s modelling goodness takes over to abstract all of this for us.
It struck me, that the only way to see the underlying composition of the model properties, is to examine the database table in, for example Sequel Pro (or your GUI tool of choice), or perhaps by connecting to MySQL in terminal and running the queries. It’s a hassle.
How most people deal with this, is to maintain a docblock at the top of each class, that sets out the properties on the model. There are two problems with this approach though. First, if you don’t keep this up to date, it is entirely useless. And second, if you haven’t done this, it’s difficult to retro-fit it.
So I decided to create a command for Laravel’s command line interface, Artisan, that would allow me to examine the schema on any model. The idea is, that even if I check out someone else’s Laravel project, I can quickly add this composer package and have access to examine the models in a few moments.
Now I can type…
$ php artisan schema User
…and I get to see the table definition for the User model. It’s simple and rugged, but it works. The workflow is simple under the hood too:
- Identify the class, by first assuming it’s in the application namespace, then attempting to check if it has a namespace passed in the argument.
- Create a new instance of the class, and use Eloquent’s built-in method to find out the table used by the model. This is important, as it will look to see if an explicit table name has been set, or fall back to the conventional name if not.
- Then, we simply use SQL’s own “DEFINE” method on the table name to pull back the table definition, and then print it out in a nice table at the console.
Next, is making it create those docblocks on request too, and some nifty logic to ensure that it’s careful about which docblocks to modify automatically, and including information about relationships, but all of this is coming in the next release. For now, it simply takes a few extra steps out of identifying the composition of the model.
Try it out for yourself, and let me know what you think.