So, no it's not an error or indexing problem. It is an design issue. Changing this behavior can be done but might cause other unwanted effects for people (or tools) that make use of this feature that look for more objects at the same time.
Dear David, if this is a design issue why doesn't give whois -h whois.ripe.net "panigl woeber" a result ? Both are valid person objects ! Or do I need a special whois client for this multi-object behaviour ? If it is a design issue (restricted by some DBM implementation) could you then please give us a hint how to specify in a whois query, that "Stefan Anders" isn't meant as multi-object but as single-object lookup (perhaps there is or could be a switch for running such a request in slow-mode without using the incomplete index) ? Daniel's suggestion "Please use handles" is nice but should we now go into querying for "SAn-RIPE" (for n=1..10000) and collect all "Stefan Anders" out of the result if we don't know the handle for a given person ? Doesn't sound very healthy ... Kind regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl@CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---
Dear Christian,
Christian Panigl, ACOnet/UniVie +43 1 4065822-383 writes :
So, no it's not an error or indexing problem. It is an design issue. Changing this behavior can be done but might cause other unwanted effects for people (or tools) that make use of this feature that look for more objects at the same time.
if this is a design issue why doesn't give
whois -h whois.ripe.net "panigl woeber"
I hurried too much here, it does this *internally* to find the object. 1) it breaks up the key 2) it does a search for all the keys 3) computes the intersection of the matches 4) check if all the matching objects indeed have all the keys ( not with -F) 5) output the remaining objects So in you example it breaks at point 3) In the question of Joachim it breaks at point 2) because it finds too many objects for both parts of the key. (Stefan & Anders) (You might want to try this out with my own name, it finds too many entries for David but it will find my person object when it looks for Kessens and thus it will pass stage 2... when doing a search for 'David Kessens')
If it is a design issue (restricted by some DBM implementation) could you then please give us a hint how to specify in a whois query, that "Stefan Anders" isn't meant as multi-object but as single-object lookup (perhaps there is or could be a switch for running such a request in slow-mode without using the incomplete index) ?
The DBM implementation limits the number of objects that can be found back. We are currently trying out the BSD DB package that has much less restrictions and that will enable us to increase the (internal) "too many objects found" limit.
Daniel's suggestion "Please use handles" is nice but should we now go into querying for "SAn-RIPE" (for n=1..10000) and collect all "Stefan Anders" out of the result if we don't know the handle for a given person ? Doesn't sound very healthy ...
Agreed, you should be able to find the persons in case you don't know their nic handle. When we move to the BSD DB package it should be possible to change this. I put this on my list. Kind regards, David Kessens RIPE NCC
Kind regards Christian
--- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl@CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---
participants (2)
-
Christian Panigl, ACOnet/UniVie +43 1 4065822-383 -
David.Kessens＠ripe.net