[Dbix-class] Designing a system with DBIx::Class
morgonhed at yahoo.com
Fri May 1 23:19:32 GMT 2009
<< Manage the scoping yourself
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").
--- 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
> > 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
> > 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
> > 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
> 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
> 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
> 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
> 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://email@example.com
More information about the DBIx-Class