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

Morgon Hed morgonhed at yahoo.com
Fri May 1 23:19:32 GMT 2009


<< Manage the scoping yourself

Hmmm. 

First of all many thanks for your reply.

What I want is a way to "lazily" only load those objects from the database that are actually needed to process a message and so ideally I would like each object to be able to get a ref to another in a uniform way without having to know wether or not the object has already been loaded...

I was actually thinking about building a little cache that would hand out weak references so that all objects that needed a reference to another object would use the same ref which would then garbage-collected when nobody needs it anymore - I assume this is pretty much what Class::DBI has been doing - is that a bad idea (and if so why)?

Maybe you could elaborate a little more how you build your object-level as your "Manage the scoping yourself" is not too clear to me (I assume you mean more than simply "make sure you load every object only once").

Many thanks!



--- On Thu, 4/30/09, Matt S Trout <dbix-class at trout.me.uk> wrote:

> From: Matt S Trout <dbix-class at trout.me.uk>
> Subject: Re: [Dbix-class] Designing a system with DBIx::Class
> To: "DBIx::Class user and developer list" <dbix-class at lists.scsys.co.uk>
> Date: Thursday, April 30, 2009, 6:46 PM
> 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/
> 
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
> 


      



More information about the DBIx-Class mailing list