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
