> $foo->bar->foo; # bam, circular reference, memory leak Yep.
That is exactly why I wanted the objects not to store refs to each other but only hold ids (i.e. primary keys). If I now had an OR-mapper like Class::DBI I could then use it to get a ref to the SAME object whenever I need it. Evidently this simple approach does not work with DBIx::Class but it may be my design that is flawed... Somehow I just cannot warm to the idea of manually managing a cache... So now I have this problem to figure out, don't yet know how to use Oracle's XMLType with DBIx::Class and have to think about how to hide all the DBIx::Class stuff behind some Moose-metamagic (I don't like this double-declaring of attributes that seems to be the norm when using both Moose and DBIx::Class). Hmmm, a lot trickier than I had thought initially... but many thanks for all replies! --- On Sat, 5/2/09, Matt S Trout <dbix-cl...@trout.me.uk> wrote: > From: Matt S Trout <dbix-cl...@trout.me.uk> > Subject: Re: [Dbix-class] Designing a system with DBIx::Class > To: "DBIx::Class user and developer list" <dbix-class@lists.scsys.co.uk> > Date: Saturday, May 2, 2009, 1:24 PM > On Fri, May 01, 2009 at 04:19:32PM > -0700, Morgon Hed wrote: > > > > << 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)? > > Foo has_one bar => Bar > > Bar belongs_to foo => Foo > > $foo->bar->foo; # bam, circular reference, memory > leak > > I think I might be able to solve this but it will involve > some magic (if I > do, it'll be in DBIC 09 :) > > > 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"). > > If you always traverse the graph in the same direction you > can generally avoid > loading things more than once anyway - but the other thing > is to keep a > hash of objects yourself, and just forcibly destroy them on > end of request - > > %$_ = () for values %cache; > > should forcibly break any circular references created. > > But do apply Devel::Leak or Devel::LeakTrace or similar to > double check you > got it right. > > (and I hope now you're starting to see why we haven't tried > to ship such a > thing in core -yet- - it's a much trickier problem than it > first appears ...) > > -- > 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 > _______________________________________________ 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