oh, heres a second version that fixes list.__setitem__.
the operations here are not terribly efficient but you could build
better caching scenarios if needed.
from sqlalchemy import *
from sqlalchemy.orm import *
metadata = MetaData()
objects = Table('objects', metadata,
Column('id',
yet another adjustment to ListAdapter...
class ListAdapter(object):
def __init__(self, parent, key):
self.__parent = parent
self.__key = key
def __cached(self):
try:
return self.__cached_data
except AttributeError:
also, it would take a lot more experimentation but maybe the @appender
and @remover methods could be useful here, just so that the cached
view of the data can be maintained as the data is retrieved from the
DB.Maybe its just my thought process (also since i didnt write the
collections
It occurs to me that a near analogue to this would be... storing a
collection of one man's children by different mothers. While it's
somewhat useful to have a collection of the guy's children... what if
you want to look up his children by just one mother, or by each mother
in turn. There's an
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
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
Incidentally, I tried mocking this all up entirely outside of SA by
creating a DictOfLists class that subclasses the basic 'dict'. That
worked fine, returns lists, adds and removes as desired, handles
everything as one would expect. So I don't think I'm fumbling with
the basic mechanics of it.