attached is an approach that uses just the tiniest amount of
awareness of how a mapper works, to do the whole optimized loading
scenario ahead of time, and you get an object with your two distinct
"pro" and "con" relationships, no list decoration or anything
needed. the appropriateness of this approach comes from the fact
that your optimization case is a load-time optimization, therefore
put the complexity at load time (which is easier to deal with since
it doesnt have to be concerned with collection mutability).
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
from sqlalchemy import *
class SomeClass(object):pass
class Position(object):
def __init__(self, data, type):
self.data = data
self.type = type
metadata = BoundMetaData('sqlite://', echo=True)
t1 = Table("t1", metadata,
Column('id', Integer, primary_key=True),
Column('data', String(30)))
t2 = Table('t2', metadata,
Column('id', Integer, primary_key=True),
Column('parent_id', Integer, ForeignKey('t1.id')),
Column('data', String(30)),
Column('type', String(20))
)
metadata.create_all()
class MyExt(MapperExtension):
def populate_instance(self, mapper, context, row, instance, identitykey, isnew):
# tell the mapper to populate the instance like it always does
mapper.populate_instance(context, instance, row, identitykey, isnew)
# get the "row decorator" that will translate the eager loaded row to something
# based off the columns in "t2"
decorator = context.attributes[id(mapper.props['_positions'].strategy)]
row = decorator(row)
# determine pro or con - create instance and append to either collection
if row[t2.c.type] == 'pro':
instance.pro.append(class_mapper(Position)._instance(context, row, None))
elif row[t2.c.type] == 'con':
instance.con.append(class_mapper(Position)._instance(context, row, None))
# alternatively! get the instance that was just appended to _positions
# if _positions[-1].type == 'pro':
# instance.pro.append(_positions[-1])
# ...etc
# tell the calling mapper "populate_instance" is taken care of
return None
mapper(SomeClass, t1, extension=MyExt(), properties={
'_positions':relation(Position, lazy=False, viewonly=True),
'pro':relation(Position, lazy=None, primaryjoin=and_(t1.c.id==t2.c.parent_id,t2.c.type=='pro')),
'con':relation(Position, lazy=None, primaryjoin=and_(t1.c.id==t2.c.parent_id,t2.c.type=='con'))
})
mapper(Position, t2)
sess = create_session()
sc =SomeClass()
sc.pro.append(Position("tastes great", "pro"))
sc.pro.append(Position("less filling", "pro"))
sc.con.append(Position("beer sucks", "con"))
sess.save(sc)
sess.flush()
sess.clear()
sc = sess.query(SomeClass).get(sc.id)
assert [x.data for x in sc.pro] == ["tastes great", "less filling"]
assert [x.data for x in sc.con] == ["beer sucks"]
On Apr 16, 2007, at 8:00 PM, jason kirtland wrote:
>
> Michael wrote:
>> On Apr 12, 2007, at 2:03 PM, jason kirtland wrote:
>>> [...]
>>> This does work, but because relation updates are happening
>>> outside of the InstrumentedList (i.e. not on 'analysis'
>>> directly), I'm losing the events that would normally be
>>> triggered. I don't think I can manually manage them either, as
>>> they're private __methods on InstrumentedList.
>>
>> some ideas which im not sure if theyd work, one is to not use
>> "collection_class" and to go with an approach that is more like
>> the AssociationProxy - i.e. "pro" and "con" have special
>> collections on them which proxy to the utlimate "associations"
>> colleciton, but on top of the InstrumentedList instead of
>> underneath it the way collection_class does.
>
> I've got a new implementation that uses this approach and it does
> work- but it is even more complex. If the InstrumentedCollection
> refactor (#213) allows implementors to choose when to fire add/del
> events I think this sort of pattern can be made pretty simple.
>
> On that front, I think it would be super useful if future
> InstrumentedCollection classes have access to their relation()
> arguments- e.g. a DRY ordered collection that keys off the
> relation's order_by. A chance to error out at definition time
> would be useful too.
>
> -jek
>
>
> --~--~---------~--~----~------------~-------~--~----~
> 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 sqlalchemy-
> [EMAIL PROTECTED]
> For more options, visit this group at http://groups.google.com/
> group/sqlalchemy?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
