Opened 2 years ago

Last modified 7 weeks ago

#24412 reopened enhancement

Provide single parameter that accepts all other parameters as qualified search terms

Reported by: irl Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics/Onionoo Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: #25274 Points:
Reviewer: Sponsor:

Description

This works:
https://onionoo.torproject.org/details?limit=1

This does not:
https://onionoo.torproject.org/details?search=limit:1

I'd like to give Relay Search users the ability to load larger results sets as long as they have explicitly asked for them. This would mean adding a limit:N to the search term as part of the search query which could be built using #23782.

Unfortunately, this parameter does not seem to work.

Child Tickets

Change History (5)

comment:1 Changed 2 years ago by iwakeh

The url you used above means that 'limit' was a field to search the content of, which correctly results in an error as 'limit' is no field known to onionoo.

I think you want the result you get from the following url:
https://onionoo.torproject.org/details?search=xyz&limit=3

Version 0, edited 2 years ago by iwakeh (next)

comment:2 Changed 2 years ago by irl

The semantics of it aren't great, but it does help to keep the query as a single string in Relay Search. If breaking the semantics is a terrible idea for an internal Onionoo reason then this could be implemented by parsing the query string in Relay Search and then constructing the Onionoo query with the limit parameter but that state would then be discarded if the search was re-run. Or I could just leave Relay Search with a hardcoded maximum result set size of 2000.

The largest sensible query I can come up with is for "country:de" which is around 1300 relays, but there may be broader queries people might want to do. Without the full result set loaded (which can take a while, but it's ok if it's been explicitly requested) the sorting is not meaningful as relays were excluded from the result set.

Last edited 2 years ago by irl (previous) (diff)

comment:3 Changed 2 years ago by iwakeh

Resolution: not a bug
Status: newclosed

Relay Search should keep track of the state of the limit parameter. The Onionoo syntax would be broken with such a change. Thus, I don't think that this would be an acceptable feature request either.

Closing as 'not a bug'.

comment:4 Changed 2 years ago by karsten

Resolution: not a bug
Status: closedreopened

So, it's true that "limit" is not a valid qualified search term. Here's the relevant specification part:

Qualified search terms have the form "key:value" (without double quotes) with "key" being one of the parameters listed here except for "search", "fingerprint", "order", "limit", "offset", and "fields", and "value" being the string that will internally be passed to that parameter.

Regarding the stated use case, how about you simply omit the "limit" parameter and risk receiving thousands of documents back? We're in a much better position today to handle the load than we were a few years back.

But let's also discuss whether we want to accept the "limit" parameter as qualified search term (and the other 5 that are currently disallowed). Basically, we'd provide two different interfaces: separate parameters and a single parameter. I see how the latter would be easier to use for applications like Relay Search.

Temporarily re-opening until we're clear what we want here.

comment:5 Changed 7 weeks ago by karsten

Parent ID: #25274
Summary: Search parameter limit always returns 400 errorProvide single parameter that accepts all other parameters as qualified search terms
Type: defectenhancement

So, this ticket is not a defect: "limit" is not a valid qualified search term. I'm rephrasing the summary to turn this ticket into an enhancement. We can still discuss how to implement this:

  • by extending the "search" parameter (requires major protocol change),
  • by introducing a new "super-search" parameter (with a better name),
  • by using the resource string for searches (as suggested in #25274; now a parent ticket), or
  • by discarding this idea because we don't really need it anymore.
Note: See TracTickets for help on using tickets.