Hi Cle,

let me first correct some errors:

>   (pool test)

This is a funny one. As the value of 'test' is a function definition,
you get a rather strange database file ;-)

The name "test", on the other hand, will give a conflict as there
is a directory with that name. I take "x.db" for now:

   (pool "x.db")

>   (class +Test +Entity)
>   (rel id (+Ref +String))
>   (rel src (+Ref +String))
>   (rel tgt (+Ref +String))
>   (new '(+Test) 'id "1"  'src A  'tgt B)     
>   (new '(+Test) 'id "11"  'src B  'tgt "C")    
>   (new '(+Test) 'id "111"  'src C  'tgt "D")    

If 'new' is called this way, it will not create database objects but
memory-resident symbols. You should call either

   (new T '(+Test) 'id "1"  'src A  'tgt B)     

if there is a single db file, or

   (new (db: +Test) '(+Test) 'id "1"  'src A  'tgt B)     

in the general case.

The values passed for 'src' and 'tgt' are random, depending on the
bindings of 'A' and 'B'. Probably NIL.

>   (commit)                                    
>   (? (db id +Test 1 @E) (show @E))

This would actually return no result at all, as you pass a _number_ '1'
while the key is a _string_. I suppose the double quotes got lost when
copy/pasting the expression from the console?

However, you are right in your observation:

> The last Pilog query will successively return three answers where I
> thought to get only one. I understand, why 'db' will deliver three
> results. But the question comes up, how I could formulate the query
> using only exact matches!

Yes, the Pilog queries 'select' and its small brother 'db' are intended
to return result _sets_, useful in GUI search components. For simple
direct DB accesses Pilog is rather overkill. You typically use the Lisp
function 'db' for that:

   : (db 'id '+Test "1") 
   -> {2}

The Pilog 'db' is actually a misnomer. It behaves more like the Lisp
'collect' function.

>   (? (db id +Test "1" @E) (val @Id @E id) (equal @Id "1") (show @E))
> But this would defeat the reason, why I tried to use a DB at all. I
> hoped that accessing an Edge via an index would be faster than asking
> Pilog to match against all its facts until it found a corresponding it
> could unify against.

True. Pilog is a powerful search mechanism, but you have to understand
that for a simple indexed access the overhead of setting up the query
and communicating environments from Lisp to Pilog and back is much
larger than the actual db access.

So it is not recommended, and was never intended, to use Pilog to
retrieve a single value from the DB.

> So could this be the reason that my DB solution of traversing all ways
> thru a graph is a lot slower than using Pilog facts? Both are trying to

For such a small database this may well be possible. In general, if all
data fit into memory, a non-DB version might well be faster. But I
wouln't expect a dramatic difference.

> iterate over the same graph built by 362 edges. Whereas the Pilog facts
> will allow for finding ca. 1000 ways per 1-2 seconds, the database
> solution was canceled after some time, as it did not reach the first
> 1000 solutions before I lost my patience ;-)

Perhaps you should try with the corrected version (see above). Also,
when using DB _plus_ Pilog, you get the overhead from both worlds. You
could also try a DB version without Pilog. Is this possible?

> Or is there any way to improve the performance of the DB? For instance
> by only matching exactly in the db query for a certain edge?

There are many ways to tune the performance. Perhaps you can elaborate a
little more on the details?

- Alex
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to