The main reason why I wan't to use relations is eagerloading, because it is the only way, as far as I can see, to retrieve data from DB from several objects in one request. I don't wan't each of my 50 objects requests the DB to fill its own neighbors; but fill them all in one request. Eagerloading does that that's why I want relations...
Maybe today that demand doesn't make any sense, but last time I used DB, it was much more efficient to issue 1 big request rather than 50 small ones. On Sep 11, 8:24 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Sep 11, 2008, at 2:04 PM, GustaV wrote: > > > > > > > Ok, another thing on the subject: > > > It looks like that does not work before a commit. Even a flush doesn't > > help: > > > t1 = Tile(id=1) > > t2 = Tile(id=2) > > t3 = Tile(id=3) > > t4 = Tile(id=4) > > session.add_all([t1, t2, t3, t4]) > > session.flush() > > assert t2.neighbors == [t1] > > > FAIL > > > I'd really like to use it before even a flush! :) > > well the flush is needed since you're making use of the database to > calculate what members are part of the collection. > > Assuming you haven't already accessed "t2.neighbors", it should > lazyload the items the first time you hit it. Otherwise you could > just say Session.expire(t2, ["neighbors"]). Other expiry methods > apply, i.e. Session.expire_all(), Session.expire(t2), Session.commit() > etc. > > Another option here is to do away with relation() altogether. This > would greatly simplify the whole thing: > > class Tile(object): > [EMAIL PROTECTED] > def neighbors(self): > return > object_session(self).query(Tile).filter(Tile.id<self.id).all() --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
