Ok, I tried subclassing MappedCollection and it seems like I did all
right with my made-up appender, remover, and iterator functions.  At
least I fixed various errors and got this to at least function as the
collection_class for the mapper shown above.

But I can't figure out how to tell my DictOfLists to return a list
instead of a single item.  So there's a place where I'm trying to say:
for child in some_bar.children[some_foo]:
    blah(child)
    etc.

Sadly, while some_bar.children[some_foo] at least returns something,
it returns a scalar Bar instance, not a list of Bars as I want it too.

What's the next step?



On Feb 15, 8:21 pm, Eric Ongerth <[EMAIL PROTECTED]> wrote:
> In case I didn't make it clear enough -- I've already done the
> following:
>
> 'children': relation(Bar,
> collection_class=attribute_mapped_collection('foo'),
>     backref=backref('parent', remote_side=[bars.c.id])) } )
>
> And that worked great -- if I only needed to have up to a SINGLE child
> per bar per foo.  Because the dict in attribute_mapped_collection
> expects scalar keys and scalar values, right?  It's not set up to
> collect a whole list of values per key.  And that is what I need.  Any
> given Foo is only going to appear once in the keys of any given Bar's
> children DictOfLists, of course.  But the values mapped to that given
> Foo need to be a list of Bars of any length.  Any given Bar will have
> 1..n children in the bars table; each of these child Bars will be
> related to a single Foo, but the total number of Foos is < n, so a
> parent Bar might have a number of child Bars for a given Foo, while
> only having zero or one single child Bar for some other Foo.
>
> There, I think that tells it more completely.  Sorry for the
> metasyntactic variables.
>
> On Feb 15, 8:13 pm, Eric Ongerth <[EMAIL PROTECTED]> wrote:
>
> > If anyone out there has already implemented a custom DictOfLists
> > collection class to map scalar keys to lists of values, I would be
> > grateful for the opportunity to avoid reinventing the wheel.  If not,
> > I guess I'll start working on it.
>
> > I've experimented successfully with attribute_mapped_collection and
> > column_mapped_collection and they work just great.  However, instead
> > of mapping keys to single values, I need some of my mapper relations
> > to map to a list of values.
>
> > Here is more of the picture, for example.
>
> > foos = Table('foos', metadata,
> >     Column('id', Integer, primary_key=True),
> >     Column('name', String(20)))
>
> > bars = Table('bars', metadata,
> >     Column('id', Integer, primary_key=True),
> >     Column('foo_id', Integer, ForeignKey('foos.id')),
> >     Column('value', String(20)),
> >     Column('parent_id', Integer, ForeignKey('bars.id')))
>
> > class Foo(object): pass
> > class Bar(object): pass
>
> > mapper(Foo, foos)
>
> > mapper(Bar, bars, properties={
> >     'foo':relation(Foo, uselist=False, backref='bars'),
> >     'children':relation(Bar,
> >                 backref=backref('parent',
> >                                         remote_side=[bars.c.id]))
>
> > })
>
> > ... So we have a relation of 1 Foo : many Bars.  And within the Bars
> > we also have 'adjacency' (tree-like) relations between the various
> > rows of the 'bars' table.  A Bar's children are kept in the standard
> > list-like collection class.
>
> > But what I really need is a *dict* instead of a list.  Ok, SA already
> > takes care of that.  But I actually need a list-like collection to
> > appear as the value for each key in the dict.  Specifically, I need
> > each Bar to be able to have stored children *per Foo*.  And not keyed
> > by the parent's foo, but the child's foo.
>
> > Does that make sense?  I'll be working on this immediately, but if
> > anyone can shorten my path to getting this straight I'd be very glad.
> > I'm beginning to work out the use of a custom collection_class for
> > this, but I haven't done all that much with metaclassing and the way
> > forward isn't obvious (the SA instructions about this seem to assume
> > the programmer is pretty experienced with custom subclassing etc.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to