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

[Morgon Hed]

> $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-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: 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
>