[PATCH] feat(rpc): return "providers" packages when querying by `name` or `name-desc`

[尤立宇]

>> > I'm convinced that just putting that into info would be better.
>> > Looking at the code also shows that adding by[]=provides is easier to implement
>> > as it fits better to the current architecture.
>> Glad you agree. This patch was more about opening up discussion before
>> going in and changing a bunch of stuff. Is there any offial decision by
>> the devs and a little guidence on how the implementation should look?
>
> As I already suggested before, I like the idea of adding multiple "by"
> arguments to the search. I wonder what to do with info queries. If we do
> the same thing there, wouldn't it be natural to add all the "by" types
> from search as well? Maybe info and search could/should be able to
> handle the same kind of queries and only differ in the amount of details
> returned...

>From my point of view, the search should look for the queried
substring in the fields,
while info looks for exact match. My study on the code shows the only
difference now
is how the $where_condition is built [1] and the level of detail is the same.

Here's some code highlights (v5 only). Except maintainer, search
performs a LIKE query
and info performs a IN query. Also, search only supports single
argument, while info supports multiple.

search/name:
"(Packages.Name LIKE $keyword_string)"
search/name-desc:
"(Packages.Name LIKE $keyword_string OR Description LIKE $keyword_string)"
search/maintainer:
"Users.Username = $keyword_string "
info:
"Packages.Name IN ($names_value) "

To support multiple "by" arguments, I came up with this, assuming by=by1&by=by2
search: any by fields contain the argument
WHERE (Packages.By1 LILKE $keyword_string OR Packages.By2 LIKE $keyword_string)
info: any by fields equals one of the argument
WHERE (Packages.By1 IN ($names_value) OR Packages.By2 IN ($names_value)
I think this way more fields can be easily supported.

With this in mind,
search by=name-desc would become by=name&by=desc
search by=maintainer would become info by=maintainer.
Does this make sense to you?

[1]
search: https://git.archlinux.org/aurweb.git/tree/web/lib/aurjson.class.php#n412
multiinfo: https://git.archlinux.org/aurweb.git/tree/web/lib/aurjson.class.php#n467