What goes well with DBIx::Class - the review.

In my case, it went very well with Fideos de Sepia and a nice glass of Fina Enguera.

This is not really a review of Dave's Perl School. His style is competent, informative, sometimes entertaining and pitched right at my level of Perl. Unlike the Moose school I went to in December, this lecture could have gone on for another hour discussing the finer points, but people have lives and we finished at 5pm.

This is more a bit of navel-gazing about what DBIx::Class might mean to me.

As opposed to Moose, where I'd already seen the power and wanted more, I had no real idea about dbic, other than the general feeling that I should get to know something about it. I have a local module where I hide away all the database connections I use to extract data from Oracle, Mysql and Postgres. I use DBI and my skill with SQL is just good enough to get what I want. It's not as onerous as building an object class before Moose came along, so I didn't come back from the School with the immediate urge to convert all my code.

Don't get me wrong - I see the shiny in abstracting away the database interface by letting you describe the data and I will look for an excuse to write new code in dbic, but I'm not seeing the immediate win in migrating. Sure, the dbic will go and read the schema and set up the accessors for me (which you have to admit is really cool), but I already had to read the schema myself to figure out how to get the data out. It's a big win if you need to create a schema from scratch, but is there a way of getting data out of existing tables that I don't intimately know and may not have foreign keys linking tables? Is this where I should be using dbicdump?

Maybe it's a bit like 2001 where I was introduced to Test. I wrote a few because other people said it was a good idea. It wasn't until 6 months later when a test bubbled up a logic error and saved my sanity that I truly understood the power of testing. Perhaps I will experience the same epiphany after I start to use it. That time might come sooner than expected ever since Oracle's accounting script found a feature that silently got turned on at our installation, we've never used, but is horrendously expensive. The Director was livid and wanted to know how fast we could move to Postgres or even (shudder) SQLServer.

Cool Things


  • Building SQL statements on the fly - the week before the class, I found myself having to wanting to switch between a select on one table and select joining 2 tables depending on the parameters passed to the function. I think dbic would have saved me some headache

  • Doesn't duplicate the schema - I mentioned this earlier. It's just the Right Thing to do.

  • Creates a PNG of the schema using SQL::Translator - Shiny!

  • DBIC_TRACE shows the SQL that would be generated by your call

  • Generates tables on the fly - why didn't I know about this a couple of years ago!


Other things: Transactions, chaining result sets, find() returns a single row.


Things you need to understand:
The difference between a Result and a ResultSet. I think if you can grok what a ResultSet is quickly, this module will be your mollusc. Time will only tell whether I do or not.

Food

As planned in the last entry, I did make it to the tapas bar after the school. Nice place just off Old Street, only 10 minutes walk from the Google Campus. Not cheap, but the food was excellent. As everyone else had scurried home, I was on my own. The croquetas I could have happily shared, lovely as they were. Very fine crust and good flavour, but a bit creamy to have all 4 to myself. The fideos de sepia (cuttlefish with pasta noodles) was just a whim - something I've never had before. It was excellently prepared while I watched, the seafood just a little crunchy and ... odd. I still don't know if I like it, but it was worth the £10.

I would go again the next Perl School I come down for (Dave may have his arm twisted into giving sessions on Testing or Web frameworks) and with the menu in hand you could order immediately on arrival and be back for the afternoon session. On the other hand, some of the others came back with Vietnamese takeaway lunch box which looked rather tempting.

So, here's an apt simile. DBIx::Class is like cuttlefish. Intelligent, tasty, slightly mysterious and I'm still making up my mind about it.

2 Comments

Nice post. I enjoyed reading this, and the final paragraph made me smile.

I've had a couple big wins on a DBIC schema as well. (I'm in the situation where I'm designing a new schema from scratch, but what I'm actually doing is writing a "canonical" representation of my schema in SQLite-style SQL and running that through a well-known dbicdump incantation. Then hg diff tells me if everything got translated OK.)

  • $schema->deploy(). This makes my test suite so much more readable. I use a tiny setup/teardown module and just do ->deploy in the setup, on a brand-new SQLite database everytime, in memory if I can get away with it. The necessary fixtures and everything get installed on a pristine database for every call to run_tests, it's brilliant. And it forces you to have a trivial way to deploy your database later.
  • An object-oriented framework where I can put business logic closer to the actual model, e.g. set_password and check_password methods on the User class. There are other ways to do this but having DBIC and dbicdump really kickstarts the thing for you.
  • Incremental filtering/searching. Some of my code looks like, roughly, $resultset = $resultset->search({ foo => $foo }) if $foo, where $foo is a parameter I got from a web form. Repeat for however many parameters there are in the form. DBIC is highly more readable than handcrafting SQL queries. Actually, anywhere you have to build SQL queries on the fly (as opposed to crafting them once and for all), DBIC/SQL::Abstract really shines.
  • Trivial abstraction of some SQL, e.g. having SQL::Limit::Abstract do its work automatically.
  • With Schema::Versioned, you can encode on the database what version of the schema is currently deployed, and you get warnings if you don't access it with a matching version of your DBIC schema. This doesn't seem like a big deal until it stops you from deploying an application on the wrong database schema. Plus you can manage your set of upgrade SQL files.

I can't see myself not working with DBIC for future developments either, at least in cases where your data is highly normalizable. It doesn't do well in ETL-style tasks but that's not an ORM's job anyway.

Leave a comment

About Enkidu

user-pic I am a Freelance Scientist** and Perl is my Igor.