Arnd Vehling wrote:
Tobias Cremer wrote:
Yes, but only for the same kind of attributes, right? Means I cannot search for admin-c and mnt-by in the same -i query like I would do with
whois -i tech-c,mnt-by toc76-ripe,CW-EUROPE-GSOC
but of course
whois -i admin-c,tech-c toc76-ripe
works.
Right, i need to do searches on different inverse-attributes in one query. And i would like to only get those objects back which match both inverse attributes.
So the question if it is a OR or a AND operation is a second point beneath that and would apply to searching only i.e. "pn" attributes and serching multiple different attributes.
Right, would be cool to be able to specify if one wants to "AND" or "OR" the returned objects.
@DevTeam, would it be possible to get this in sometime soonish?
Actually, it might be nice to rethink the query mechanism a bit further. There are a few limitations with the current setup. Problem 1: ROUTE/ROUTE6 searches There is no way to specify that you want only ROUTE or ROUTE6 objects with a specific "origin:" attribute: $ whois -T route -r 62.23.0.0/16 route: 62.23.0.0/16 descr: FR-COLT-FRANCE origin: AS8220 ... route: 62.23.0.0/16 descr: FR-COLT-FRANCE origin: AS6675 ... Problem 2: PERSON searches Searching for PERSON objects sometimes returns results that are not desired. This can happen if the name in a person object matches the string of a "nic-hdl:" attribute, like when looking for "KIRI": $ whois -T person -r kiri | egrep '^((person|nic-hdl):|$)' person: Kiri Butler nic-hdl: KB9435-RIPE person: Kiri Georgiou nic-hdl: Kir5-RIPE person: Aasish Kiri nic-hdl: AK3283-RIPE person: Robert Kirmayer nic-hdl: KIRI The database has no way to know if you are looking for the "nic-hdl:" or the "person:" attribute that matches. Possible Solution A: multiple inverse queries We can solve problem 1 (multiple "origin:" attributes), and Tobias' original problem, by allowing multiple inverse queries in a logical AND operation. We'd need to change the meaning of multiple "-i" flags though. Right now, if you type: $ whois -i tech-c -i admin-c swk1-ripe It is the same as: $ whois -i tech-c,admin-c swk1-ripe The database *could* be changed to interpret them differently: $ whois -i tech-c,admin-c toc76-ripe Would work the same, but if you have more than one "-i" flag, you would list the keys separately: $ whois -i tech-c -i mnt-by toc76-ripe CW-EUROPE-GSOC Limitations are: o This does not work for problem 2 (ambiguous "person:" and "nic-hdl:" attributes). o It is not exactly simple for the average user to understand. Possible Solution B: SQL-like searches While we would be reluctant to allow actual SQL searches into the database, we might be able to open the database up to an SQL-like search language: $ whois --search tech-c='TOC76-RIPE' and mnt-by='CW-EUROPE-GSOC' $ whois --search nic-hdl='kiri' Problems: o One could perform some extremely non-optimal searches. (We could possibly avoid most of this problem by requiring that some key is present in the search.) o A second query language for users to learn. We would be unlikely to be able to implement either of these before the RIPE meeting, but could begin before then (after the pending abuse changes). Apologies for the long delay in replying, but I was nervous about raising the idea of SQL-like searches, and wanted to wait before mentioning it in public. -- Shane Kerr Software Engineering Department Manager RIPE NCC