Monthly Archives: April 2013

My “fix” for preserving timestamps on import with Laravel

Edit: This will not work on “updated_at” btw, for reasons that become obvious very quickly, but for my application, this is not an issue.

I’m currently re-developing a Coldfusion app in Laravel 4. Most of the current db tables have “createdat” and “updatedat” fields. I went thru the trouble of creating migrations for all of the db tables and then writing an Artisan command called “Import” that connects to a copy of the old db and imports all of the data into the new db created with the migrations that includes a few schema changes that are crosswalked over.

One of the problems with this is that the timestamp fields (“created_at” and “updated_at”) created by Laravel during migrations will be current(as in “now”) even if I try to map the old timestamps on import:

//no workie
$videogroup->created_at = $vg->createdat;

As a result, I lose important timestamp info. from my old database.

My new fix involves running the import as before:

$videogroups = DB::connection('mysql_vm_old')->select('select * from videogroups');
foreach ($videogroups as $vg) {
$videogroup = new VideoGroup;
...
$videogroup->save();

Except that I add this to the loop:

$videogroup->createdat  = $vg->createdat;

Then after the initial table import is complete, run:

$videogroups = VideoGroup::all();

//replace default timestamp value with the one from the old db
foreach ($videogroups as $vg) {
$vg->created_at = $vg->createdat;
$vg->save();
}

//get rid of the temporary 'createdat' column
Schema::table('videogroups', function($table)
{
$table->dropColumn('createdat');
});

This certainly adds more overhead to my import script for larger tables, and I’ve already had to increase mysql’s memory limit to handle the script as it’s grown, but once the site goes into production, I’ll no longer need the Import script.

As it stands now, I’m running the following on a daily basis as I make changes:

php artisan migrate:refresh --seed
php artisan import

6 reasons not to use a PHP Framework

  1. You are immortal, and therefore, will always be around to help other developers understand and extend your code.
  2. You have no life, and therefore, don’t mind spending all of your free time writing code comments and documentation that would already be written in a good framework, so other developers after you (or with you) can also write code for your app(s).
  3. You are coding an app that will be one of the most visited sites on the web (all by your self and for eternity if #1 and #2 are true), and therefore, can justify the potential nanoseconds saved by not having the “overhead” of a framework.
  4. You are a web security god and are way smarter than the collective group of developers who code and test good frameworks for security issues.
  5. You want to spend all of your time re-inventing the wheel by writing your own RESTful routing implementation, ORM, templating engine, etc. etc. instead of what a good framework provides. Or maybe you skip the ORM part and just re-write larges parts of the app when you need to switch DB engines.
  6. You don’t do “deadlines”.

If these reasons don’t apply to you, I recommend checking out Laravel, or better yet, the Laravel 4 beta.

Updating related models in Laravel

Not sure how other frameworks handle this (if they do), but Laravel’s ability to simply update a related model is pretty nice.

 $video->videoevent()->update(array('event_date' => createDbDate(Input::get('event_date'))));

Assuming I have a relationship between Video and Videoevent have made ‘event_date’ available for mass assignment the Videoevent model, magic happens.