DBIx::Class is already one of the most powerful ORMs you can use in any language (but only Perl has it ;) ). Now, after a huge effort to redesign key code paths and all the requisite testing for backward compatibility you might imagine, the newly released version is significantly faster. How much faster?
Ok, so lets not use our own benchmarks, but instead those of other competitive Perl ORMs. Take a look at https://github.com/damil/compare-ORM which compares DBIC with DBIx::DataModel. We ran this test suite against the previous stable DBIC and this new release. Here's the diff:
http://www.diffchecker.com/v89swf0a
So by this bench we are seeing quite a few use cases nearly 10 times faster! Of course your results may vary, but I found my current job test suite (not exactly fast) completed better than 20% faster. That alone is a pretty sweet improvement from just an upgrade.
The new version of DBIC also include a pile of fixes and other improvements. Check out the changelog and download it and let us know what it does for you! As always you are just:
cpanm DBIx::Class
Away from all this amazing speed and power!
That's great news, but I still look forward to 0.9 and better Moose integration.
I've recently spent longs hours trying to figure DBIx along with Moose. Actually - any ORM that would go well with Moose. Unfortunately neither go too well, and it's a pity DBIx is not Moose based, though the foretold version 0.9 is supposed to be.
It may be fast on ORM but becomes increasingly clumsy from developer point of view when dealing MOP-based projects. Such where one would typically have the DATA designed in base Moose classess and different persistence engines implemented in inherited classess. I mean the same data persisted over say DBI, SOAP and Excel stores.
There is currently no elegant way to tell DBIx to get the columns from inherited base Moose Class, which means you need to duplicate all such. Yeah, modules exists, the most recent 2 years old...
There's no way to keep the Moose-based relations from the base class into DBIx, and one would likely need tons of before/after triggers to get this working if you at all decide to go the automated way.
In the end of the day - it seems that a plain "no-smart" approach saves dev. time and brings more value into the project. It's a pity, since I love Moose and DBIx, but you cant' really get them along in your project.
best,
Stelf
Posted by: stelf | 05/07/2013 at 04:41 AM