On Mon, May 10, 2010 at 09:04:48AM +0200, Henrik Sarvell wrote: > Ah I see, so the issue is on the remote side then, what did your code > look like there, did you use (prove)?
There were several scenarios. In cases where only a few hits are to be expected, I used 'collect': (for Obj (collect 'var '+Cls (...)) (pr Obj) (unless (flush) (bye)) ) The 'flush' is there for two purposes: (1) to get the data sent immediately (without holding in a local buffer), and (2) to have an immediate feedback. When the receiving side should close the connection (i.e. the GUI is not interested in more results, or the client has quit), 'flush' returns NIL and the local query can be terminated. In other cases, where there were potentially many hits (so that I didn't want to use 'collect'), I used the low-level tree iteration function 'iter' (which is also internally by 'collect'): (iter (tree 'var '+Cls) '((Obj) (pr Obj) (unless (flush) (bye)) ) (cons From) (cons Till T) ) (bye) ) So 'iter' is quite efficient, as it avoids the overhead of Pilog, but still can deliver an unlimited number of hits. Note, however, that you have to pass the proper 'from' and 'till' arguments. They must have the right structure of the index tree's key. For a '+Key' index this would be simply 'From' and 'Till'. For a '+Ref' (like in the shown case) it must be '(From . NIL)' and '(Till . T)'. 'db', 'collect' and the Pilog functions take care of such details automatically. For complexer queries, involving more than one index, yes, I used Pilog and 'prove'. Each call to 'prove' returns (and sends) a single object. For plain Pilog queries, i.e. without any special requirements like a defined sorting order, you can get along even without any custom functions/methods on the remote side. The 'remote/2' predicate can handle this transparently by executing its clauses on all remote machines. I have examples for that, but they are probably beyond the scope of this mail. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe