Michael Bayer wrote:
>
> you might want to try:
>
> mapper (someclass, sometable, properties = {
> 'rels' : relation(someotherclass, lazy=None)
> })
>
> which will turn off all loading on the "rels" attribute. im not sure
> how well thats going to work since it hasnt been tested very strongly
> within the context of a flush(), etc. but it fixes your unit test even
> when a flush() is added to the bottom.
>
I ended up opting for a different solution (remove the backref and add the
second property manually):
relmapper = mapper(Relation, rel_table)
mapper(Information, info_table, properties={
'rels': relation(Relation)
})
relmapper.add_property("info", relation(Information))
> if you have half a million "rels", then the relation() function is not
> particularly useful for loads since theres currently no way to limit the
> rows you fetch.
Well half a million was an exaggeration, but the thing that really concerns me
is that the backref caused an extra database hit when it was not needed. The
ORM certainly does not need to fetch those extra rows from the database just to
insert a new one, and the whole point of lazy relationships is to defer loading
of objects as long as possible.
>
> it seems like the overall feature youre looking for is "extra lazy
> loading", which is a pretty large feature. adding small hacks to
> attributes.py is only going to complicate the attributes module
> unnecessarily and not really going to solve the issue.
I don't think so. What you're calling "extra lazy loading" is really more true
lazy loading. The backref feature causes a lazy relationship to be loaded when
it is not needed, so it's doing a bit less than true lazy loading in this case.
>
> or maybe you just want "rels" to be there for the purposes of flush()
> but you dont care about loading; in that case maybe the above solves it
> (then again why even bother having a "rels" attribute? why not just
> define the relation in the other direction only? )
Well, I need info.rels sometimes, but I don't want them when I'm just working
with a single "rel" and its associated "info".
>
> one goal of SA is to not add huge complication to the core just to suit
> relatively rare use cases, such as heavy manipulation of detached
> objects with lazy loaders attached to them. if you want the benefits of
> lazy loading, then you have to have the objects in a session.
>
You can downplay my use case as "rare" if that makes you happy. I'm just trying
to point out that the backref feature has an annoying side affect that
circumvents the main objective of lazy loading--to defer loading until
absolutely necessary. It's OK though, I think I've found a simple solution that
works so I'm satisfied.
~ Daniel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
