see that everyone ? not so hard :) Jonas -
this has been high on my list. im attaching this patch to the ticket, which was not viewable until now since I forgot to press "submit" on it three days ago. http://www.sqlalchemy.org/trac/attachment/ticket/142 i have also been thinking of having availability like this on the lazy-loading relations of objects. but this presents a lot more ambiguity: - if i say myobj.items[3:5], do those items also get associated with a list attached to myobj.items ? or do they fall out of scope and then reloaded again when asked for again ? it seems like it would be nice to keep items[3:5] around. then if I later say myobj.items[2:15], it queries fully again but the identity map logic would prevent the existing 3:5 from being overwritten. but then, if the list is so enormous, we might not want to hold onto already-loaded items by default. but if we dont, then a lazy loading list will be querying the database all the time, unlike now where it only queries once. seems like there is not enough information in myobj.items[3:5] to determine whats better. - say we are holding onto whats loaded. I did myobj.items[3:5], then myobj.items[1:12], then what happens when I say myobj.items[2:7] ? it shouldnt query, that range has already been loaded. so the incoming range object would have to be checked against an existing list of "loaded" objects. - then, if I say myobj.items.append(x), or even myobj.items[8] = y, do we load the entire items list into memory and just forego the dynamic behavior ? it seems very complicated to manage inserted/deleted items amongst a partially loaded list. the second two items indicate the need for a much smarter list holding object. the existing list holding object already does a lot of wacky stuff by giving you the "whats added/deleted" lists for the purposes of committing. I have been thinking of creating a new list object that does everything....but it seems a little daunting at the moment. anyway thanks for the patch, hopefully it can at least go onto the main mapper methods, as we've had more than one squeaky wheel on here. Jonas Borgström wrote: > Hi, > > As most of you people already know the SQLObject.select method does not > return a list of the selected instances directly, instead a > SelectResults instance is returned. This instance can then be used to > further manipulate the search query. > `SelectResults.filter` can be used to add another "where" clause. > `SelectResults.order_by` can be used to specify the sort order. > Python slicing of the instance will also be translated into the > corresponding SQL equivalent (result[10:20] translates to OFFSET 10 > LIMIT 10) > > I've attached a simple work-alike version of this for sqlalchemy. It's > currently not integrated with sqlalchemy at all since I'm not sure > what's the best way to do that, or if it should be done at all. > > it currently works like this: > > res = SelectResults(mapper, table.c.column == "something") > res = res.order_by([table.c.column]) #add an order clause > > for x in res[:10]: # Fetch and print the top ten instances > print x.column2 > > x = list(res) # execute the query > > # Count how many instances that have column2 > 42 > # and column == "something" > print res.filter(table.c.column2 > 42).count() > > You can find more examples in the unit tests or the sqlobject > documentation :) > > Cheers, > Jonas > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
