ORM behavior with relationships from/to/between mappers, particularly
polymorphic mappers, also their usage with Query, SelectResults. tickets
include [ticket:439], [ticket:441], [ticket:448].
+ - removed deprecated method of specifying custom collections on classes;
+ you must now use the "collection_class" option. the old way was
+ beginning to produce conflicts when people used assign_mapper(), which
+ now patches an "options" method, in conjunction with a relationship
+ named "options". (relationships take precedence over monkeypatched
+ assign_mapper methods).
- extension() query option propigates to Mapper._instance() method so that
all loading-related methods get called [ticket:454]
- eager relation to an inheriting mapper wont fail if no rows returned for
class_._state = property(_get_state)
typecallable = kwargs.pop('typecallable', None)
- if typecallable is None:
- typecallable = getattr(class_, key, None)
if isinstance(typecallable, InstrumentedAttribute):
typecallable = None
setattr(class_, key, self.create_prop(class_, key, uselist, callable_, typecallable=typecallable, **kwargs))
u = s.query(m).select()[0]
print u.addresses[0].user
-class CustomAttrTest(UnitOfWorkTest):
+class CustomCollectionsTest(UnitOfWorkTest):
def setUpAll(self):
UnitOfWorkTest.setUpAll(self)
global sometable, metadata, someothertable
class MyList(list):
pass
class Foo(object):
- bars = MyList
+ pass
class Bar(object):
pass
mapper(Foo, sometable, properties={
- 'bars':relation(Bar)
+ 'bars':relation(Bar, collection_class=MyList)
})
mapper(Bar, someothertable)
f = Foo()