On Apr 28, 2008, at 4:34 AM, Kyle Schaffrick wrote:
> I have taken a first stab at this to play with the idea and it seems > to > be doing the right thing, the patch also contains some very > rudimentary > tests in ShardTest that make it voom. very nice ! > The patch adds a .merge_ordering() method to ShardedQuery that allows > supplying an ordering function that will take a short (upper limit > being > the number of shards involved) list of items and return the one that > comes first. The type of the items is whatever you would get back from > the query ordinarily. If you use it with an order_by that enforces the > same ordering, you can get a complete ordering of results for queries > that pull results from multiple shards. > > Example: >>>> q = s.query(Person).order_by(Person.age.asc()) >>>> mq = q.merge_ordering(lambda l: min(l, key=(lambda p: p.age))) > > If you don't call merge_ordering, it doesn't do any merging and uses > the > standard behavior of concatenating the results. > > "merge_ordering" is probably a crappy name, so if this gets any > interest > then we can figure out what else to call it. One aspect I'm not sure > about is whether or not merge_ordering's parameter should use the > protocol it's using now, or if it should accept something more like > "key" or "cmp" parameters of the builtin list.sort method. so, lets name it _merge_ordering() to start so we have some future leeway on the name. > Also, I attached a better version of the iterator patch that closes > the > result object like the original code did, by hooking each iterator > with > a call to result.close(). I couldn't figure out if this was actually > nessecary because it didn't seem consistent between Query and > ShardedQuery, but that may be for reasons I'm not seeing. Well, in fact the result.close() at the end there is not really needed; when all result rows are exhausted, ResultProxy will issue close() on the cursor anyway (and if the connection itself was created with close_with_result=True, the Connection will also be returned to the connection pool). So in this case its probably better if shard.py were using session.execute() instead of session.connection(), since this allows the Session to make the choice, based on transactional state, if the Connection should be a close_with_result or not. I think the reason shard.py isnt doing that right now is because there were more paramters to be sent to connection() that ShardedSession adds, so ShardedSession would need a corresponding "execute()" method added which works in an analgous way to Session.execute(). All in all its a great patch and if you can make those adjustments that would be great. Thanks ! - mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
