Hi Ashley,

> Just a though I've had a note to post about for ages.
>
> If you've got Parent and Child models, where "Parent has n :children",  
> and you call Child#destroy on a Child in the Parent's collection,  
> should the Child be removed from the collection?  I'm thinking  
> something like this:
>
>    child = Child.new
>    parent.children << child
>    parent.children.include?(child) # => true
>    parent.save
>    child.destroy
>    parent.children.include?(child) # => false
>
> Is this desirable behaviour?  It's something I've run into, but not  
> something I've immediately felt strongly one way or the other about.  
> Is it worth a ticket?

I'm not sure this would be completely obvious to a DM user.  It would
be like calling a method on an object and having that object removed
from one or more of the Arrays it belongs to.  It could be argued that
DM should have richer behavior than plain ruby objects, and I would
agree, but at the same time I would want DM to remain ruby-ish with
similar behavior to other ruby libs. I don't think we should have this
behavior be a part of core.

Implementing this might not be entirely straight forward either.
Every resource would need to hold references to every single
collection it was ever included within, and tell them to itself when
it is destroyed.  I'm not sure what side effects that would have.  I
also wonder if there might be GC issues in long running code because
you may have references to collections that normally would've gone out
of scope.

A side note is that internally each resouce does hold a reference to
the collection they were retrieved from, if any, for SEL purposes.  I
was hoping to change that and actually make it so the Resource only
holds a reference *inside* Collection#each, which simplifies the whole
orphaning/relating system inside Collection.  The simplified behavior
also opens the door to more advanced behavior like SEL inside N level
deep loops with (I hope) relatively minimal effort.  There are a few
related tickets for this, but I've had to defer them because the
current SEL system can only handle loops 1 level deep.

--

Dan
(dkubb)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to