Re: [SQLObject] relationship interface and lists..

[Ian B. <ia...@co...>]

On Tue, 2003-05-20 at 06:55, Bud P.Bruegger wrote:
> I've been thinking about the API for dealing with relations.
> 
> person.roles is just perfect.
> 
> In addition, what about person.rolesWhere(<some condition>)

Well, you can create a select query to do this, but you have to specify
the join explicitly.  Maybe with the interface below, it could look like
person.roles.select(condition).

> And instead of person.addRole(r), what about person.roles.append(r)
> and similarly, r.removePerson(p) as r.persons.remove(p)

I started on this path, where joins returned a result of some sort,
subclassing lists.  But I realized I was getting to distracted at what
was an early point of development, so I didn't do it.  I might make that
change yet.  However, the result would look more like SelectResults, and
not a subclass of list.

> To be pythonic, everything should behave as much as a list as
> possible.  So I started to play around with inheriting from list and
> looking at the hooks (see attached file).  I was expecting that there
> was a single interface to setting and getting list items (namely,
> __getitem__ and __setitem__), but it seems that other ways of
> modifying the list such as l.extend() or l.append() don't internally
> fall back on __getitem__ and __setitem__.  

I think it's easier to make it an iterable object, with list-like
methods, like SelectResults.  Then if you want a list that doesn't
change underneith you, you just call list(person.roles).

Joins are also more like sets than lists, so that would be a better
interface model.

  http://www.python.org/dev/doc/devel/lib/set-objects.html

> Also, someone could "recalculate" relationships and assign them:
> p.roles = throttleBack(p.roles)

I'm not sure I understand what you're thinking here.  

  Ian