On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote: > I find the Rails ActiveRecord interface pretty appealing: > > http://ar.rubyonrails.com/classes/ActiveRecord/Base.html
DBIC's interface is not dissimilar although it favours data structures for query descriptions rather than raw SQL. > I like the notion of protected fields (attr_protected and > attr_accessible) to allow mass assignment directly from the > request parameters. This is perl. my @ok = qw(foo bar baz quux); my %set; @[EMAIL PROTECTED] = @{$c->req->[EMAIL PROTECTED]; $dbic_obj->update(\%set); # but gods please validate first for production > I like how if you fetch columns that don't exist in the table > the object becomes read-only by default. That's neat, although I prefer tools that presume I know that I'm doing. > And the find() interface seems nice, where basically the > select is just broken into its components (e.g., condition, > order, group, limit, offset). I know they add a bunch of > helper fetch methods through their autoload mechanism. Yeah, I find this kinda funny. Rails guys go "look, LOOK" about the equiv. of find_by_login($login) DBIC just handles find({login => $login}) which saves autoload madness at the cost of ... TWO CHARACTERS ... > So with that design you'd get the centralized validation, which > is most critical to me, but then you could use SQL freely > and get back a collection of read-only active record objects > if you did fancy stuff. You -can- pass a custom chunk of SQL to DBIC for the where clause and have it Just Handle It. The fact that most people choose not to is, however, a hint as to where the better engineering practice lies :) > I'll read through DBIx::Class some more. The thing where the > models are used through the schema seemed weird to me and I don't > fully understand it yet. I'd really like to be able to "use Try::User" > and be able to create and update it rather than going through an > explicit db schema layer. I guess I could create another object > that wraps around the DBIx::Class module or something. Under Cat you'd just be doing $c->model('DB::User') and everything would work. The reason for the explicit schema object is to handle multiple connections elegantly (see recent blog madness for the nasty hacks used to make AR sort of handle it if you change all your code to use a different syntax). If you're sure you only need one connection, DBIC -will- let you set the connection at the class level. It's just kinda gross so people generally don't. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Director Want a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/