[Dbix-class] Designing a system with DBIx::Class

Matt S Trout dbix-class at trout.me.uk
Thu Apr 30 22:46:01 GMT 2009


On Thu, Apr 30, 2009 at 07:21:45AM -0700, Morgon Hed wrote:
> 
> Hi!
> 
> I am currently evaluating DBIx::Class as a ORM-solution for a new system and I wonder either my design is flawed or DBIx::Class simply is not the right tool for me...
> 
> I have a number of classes (all based on Moose) that I need to persist in an Oracle-database. The application is driven by messages that are received via Oracle Advanced Queuing. 
> 
> To process a message I have to retrieve a number of collaborating objects from the database (which then in memory form some sort of tree or graph) where calls are made from e.g. a child-object to a parent-object, and the other way around to finally reach an end-state at which point the whole object-graph should be persisted again to the database.
> So the whole thing should work like this:
> 
> 1) dequeue message
> 2) build object-graph
> 3) process message in the graph
> 4) update graph in database
> 5) commit
> 
> I.e. the final commit not only commits all changes to the object-graph but also the dequeuing of the message in one transaction.
> 
> In such a context I would like each database-entity (given by it's primary key) to be represented by exactly one instance on the object-level (which Class::DBI actually does) but the philosophy of DBIx::Class seems to be different, for instance if I do this:
> 
> my $h1 = $schema->resultset('Hubba')->find(1);
> my $h2 = $schema->resultset('Hubba')->find(1);
> 
> I get two different instances both representing the same database-row which makes it a bit harder to build the graph I have in mind.

Yep, you do.

That's because the silly approach Class::DBI used caused memory leaks.

We don't like memory leaks.

> Can someone please give me some advice here?

Manage the scoping yourself - you'll find it's not actually that much code
and the finer grained control will make your life a lot easier.

I do heavy OODB style stuff in DBIC quite a bit - one of our clients was
kind enough to let me give: http://xrl.us/oubg6 at the PostgreSQL WEST
conference showing how we built it up for the http://airspace.co.uk/
hotel booking system - a small number of root classes and dozens of child
classes all FKed up nicely, and the scoping stuff didn't get in our way at
all.

-- 
        Matt S Trout         Catalyst and DBIx::Class consultancy with a clue
     Technical Director      and a commit bit: http://shadowcat.co.uk/catalyst/
 Shadowcat Systems Limited
  mst (@) shadowcat.co.uk        http://shadowcat.co.uk/blog/matt-s-trout/



More information about the DBIx-Class mailing list