Do Moose and DBIx::Class go together like bread and butter? I'm currently using Moose and DBIx::Simple but I have a sneaking feeling that DBIx::Class would be sheer nirvana in this situation.

OK, so I have a bunch of classes which all inherit a base class method to obtain new data:

sub getnew {
    my ($self) = @_;

    $self->dbs->query($self->getnewsql)->hashes;
}
[download]

Now, getnewsql is a lazy-built method. In the first level of derived classes, the following role is used by some classes to get new data:

package Local::GetDataTable;

use Moose::Role;

sub _build_getnewsql {
  my ($self)=@_;

  sprintf "SELECT * FROM %s WHERE qblistid IS NULL and qbresponse IS N
+ULL",
    $self->dbtable;

};

1;
[download]

Now, in a class which needs to refine the WHERE clause with another clause, we override this lazy builder as follows:

override '_build_getnewsql' => sub {
    my ($self) = @_;
    my $sql = super();
    $sql .= sprintf "AND location = %d", $self->location;
};
[download]

eewww, it's so stringy

I wonder if there is some way to do this with methods? DBIx::Class uses data structures to build SQL via SQL::Abstract and so the lack of methods there makes me wonder if there is a way to extend the query data structures in an OO-fashion

make a view my friend?

ORMesque has a different take on object-relational Perl - simply build database views for each thing you need. Why am I doing all this dynamic query extension in OO Perl anyway? An alterative approach would be to simply map my various program query requirements to database views.

I think it's interesting to explore how best to tread the line between programming languages and relational database engines. I suppose that using an ORM allows you to be more dynamic but I'm not sure.

recent threads

a recent thread shows resultset restriction but not extension. I'd be curious as to how to extend things with DBIx::Class... or your opinion on database views as an alternative approach.

living breathing code

I wrote DBIx::Cookbook to build up an executable comparison reference, so contributions there are welcome too.

The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"

Comment on DBIx::Class, make me drool Select or Download Code

Replies are listed 'Best First'.

Re: DBIx::Class, make me drool
by armstd (Friar) on Aug 26, 2011 at 14:14 UTC

I've only used DBIx::Class for one project, but I was completely sold on it once I was done. Unwriten SQL is the best SQL imo. Having every object map directly to a table row (whether a real table or a view) will definitely make your life easier. Doing common joins in a SQL client or in Perl is not very reusable in the network service sense. Java ORM clients will directly benefit from any views you create, but not from any SQL or Perl you write.

One annoyance I found using DBIx::Class, you end up with DBIx::Class objects, in a reserved DBIx::Class namespace. You don't really want to be doing anything other than DBIx::Class with those objects, so you end up with a spur on your namespace, where special objects exist that look nothing like any other objects. In my case SQL wasn't my only backing store, it was just a readonly copy of my Perforce metadata, along with additional business logic metadata. My SCM objects wanted to talk to Perforce for readwrite things, SQL for reporting and other things to avoid locking up Perforce. They could not simply isa DBIx::Class resultsets, they had to hasa resultsets, given the special DBIx::Class package structure.

In the end, the value DBIx::Class delivered in code agility and maintainability far exceeded the awkwardness of designing the namespace for ideal separation of concerns.

--Dave

[reply]