Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

And back to deleting objects. If A has many Bs, there should be a way of 
declaring it an 'owned relationship', in terms of 'when I delete A, all my Bs 
are deleted'.

Perhaps a flag on MultipleJoin. destroyChildrenWhenDestroyed=True 


john

On Monday 10 November 2003 16:05, you wrote:
> On Nov 10, 2003, at 2:02 AM, John Baker wrote:
> > On Monday 10 November 2003 00:57, Ian Bicking wrote:
> >>  From a quick inspection of the code, no, that's not implemented.
> >> Yes,
> >> it should be.
> >
> > Goodo. Will it appear in the next version? Should only be a few lines
> > I'd
> > guess?
>
> Yes, it should probably go into the next version.
>
> >> Hmm... right now if, say, you have a many-to-one relationship between
> >> Replies and Stories, then you have Story.replies.  But that's just a
> >> dumb list.  I've thought about an addReply-like method, which would
> >> assign the story_id column of Reply.  But I don't quite like it,
> >> because you aren't just adding the reply, you are moving it (if it
> >> previously had a story).
> >
> > Yes, that's right, and consistent. It seems rather odd assigning Reply
> > to a
> > Story through the new method on Reply ...
> >
> > Reply.new(... story = s)
> >
> > That's odder :)
> >
> > If you think in terms of OO and you're used to Collections, you think
> > about
> > adding something to a Collection.
>
> No, it's quite different from a normal collection.  Normal collections
> -- in Python and most other languages -- are many-to-many, i.e., an
> object can be part of multiple collections.  One-to-many relations
> typically imply something more like ownership.
>
> It might be reasonable to "add" a reply to a story if the reply's story
> is already None, but in the more general sense the reply is being
> "moved", not "added".
>
> --
> Ian Bicking | ia...@co... | http://blog.ianbicking.org

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info