AUR web interface

**This is the bug tracker for the AUR web interface.**

Use this tracker to report bugs or make feature requests regarding the behaviour or implementation of the AUR software.
Please read the Reporting Bug Guidelines before filing a new task.
https://wiki.archlinux.org/title/Bug_reporting_guidelines

- Please report bugs related to Arch Linux official packages here: http://bugs.archlinux.org/index.php?project=1
- Please report bugs for [community] packages here: http://bugs.archlinux.org/index.php?project=5
- For any packages in the AUR contact the maintainer or leave a comment on the package's detail page.

Source Code:
https://gitlab.archlinux.org/archlinux/aurweb/
Tasklist

FS#10487 - PATCH: aur-rpc custom search fields

Attached to Project: AUR web interface
Opened by pajaro (pajaro) - Saturday, 24 May 2008, 15:58 GMT
Last edited by Loui Chang (louipc) - Sunday, 10 August 2008, 16:09 GMT
Task Type Feature Request
Category Backend
Status Closed
Assigned To Simo Leone (neotuli)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
- Patch that allows you to specify custom fields when performing searches in AUR-RPC (rpc.php).

Additional info:
* I couldn't test it, because i don't know how to clone the aur database.
This task depends upon

Closed by  Loui Chang (louipc)
Sunday, 10 August 2008, 16:09 GMT
Reason for closing:  Won't implement
Additional comments about closing:  RPC search now returns all info instead of custom fields.
Comment by eliott (cactus) - Sunday, 25 May 2008, 05:09 GMT
A major point of the json query interface was to be as efficient as possible.
We *wanted* to push the logic operations to the client, not have the service doing any uneccesary processing.

This idea does seem fairly sound though.
I will give it some serious thought.
Comment by pajaro (pajaro) - Sunday, 25 May 2008, 16:15 GMT
I am gonna expose why i think that rpc.php you have custom fields in the searches.

Preliminar information:
now the clients that query the rpc interface, like arson, have to perform N+1 queries, where N is the number of results.

CLIENT SIDE
From my house each query takes around 600ms. This gives me more than 4 minutes to complete the command "arson -S kde" (421 results -> 422 queries to the aur rpc.php)

SERVER SIDE
I think that 1 request + 1 mysql query is far more efficient that N+1 requests + N+1 MySQL connections + N+1 mysql queries.
Also, if you go to http://aur.archlinux.org/packages.php, you get the expected behaivour. A query takes the expected time, not minutes. But there is one difference: maximum 100 results per page.

DEVELOPER SIDE
Pushing operations to the client is good, but I think think that enforcing N+1 http queries is going too far, specially when what aur-rpc does is not much more than a SELECT to a table/view and the necessary input/output filtering needed in the http world.

USABILITY SIDE
One of the requierements for usability is to avoid unnecessary delays.
Now you get two sources for AUR queries:
a) http://aur.archlinux.org/packages.php - usually takes LESS THAN 2 SECONDS to give you the information you need.
b) http://aur.archlinux.org/rpc.php - usually takes MORE THAN 1 MINUTE to give you the information you need.
So, if you are a developer of an aur client, like i do, option b gets discarded right away.


I hope that with this exposition you understand better what motivated me to develop this patch.

Comment by eliott (cactus) - Sunday, 25 May 2008, 23:24 GMT
> a) http://aur.archlinux.org/packages.php - usually takes LESS THAN 2 SECONDS to give you the information you need.
> b) http://aur.archlinux.org/rpc.php - usually takes MORE THAN 1 MINUTE to give you the information you need.

I guess it depends on what operation you are performing, and how close you are to the server.

> From my house each query takes around 600ms. This gives me more than 4 minutes to complete the command "arson -S kde" (421 results -> 422 queries to the aur rpc.php)

I have no idea what "arson -S kde" does. I don't use it, so how would I know?
Trying to derive what you are talking about, I can only think about how "pacman -Ss kde" behaves.
"pacman -Ss" only returns a package name and a brief description for the matches.

Are you saying that for every search style query, you also look up the details on each result before returning any results to the user, even if that may not be the package the user wanted information on?

> Also, if you go to http://aur.archlinux.org/packages.php, you get the expected behaivour.

What is the expected behavior?
This is a vague statement.

Let me try to be psychic for a minute, since what you are saying isn't really clear at all...

Are you saying that you want to see the *same information* as you see in the web interface when you get search results?
The (Location,Category,Name,Votes,Description,Maintainer) tuple?

Now *that* is a feature request I could see as reasonable.

Note: I probably wouldn't want to see any join logic (foreign table data) returned in the initial result set though (or at least no complex join data). I don't remember offhand what is being done to generate the aur web search result data.
Comment by pajaro (pajaro) - Monday, 26 May 2008, 00:47 GMT
>I have no idea what "arson -S kde" does. I don't use it, so how would I know?

arson is an aur package search application that uses aur rpc, so "arson -S kde" searches for kde in aur. It returns the same information than pacman -Ss.

> Are you saying that for every search style query, you also look up the details on each result before returning any results to the user, even if that may not be the package the user wanted information on?

Let me correct you: the user almost always wants more information than just the package name when he performs a search, and i don't look up for details on each results, I just add more fields to the same query to the database. (At this point i can't know if Packages is a table or what).

aur-rpc has 2 queries:
to search: SELECT Name,ID FROM Packages WHERE...
to getting info: SELECT ID,Name,Version,Description,URL,URLPath,License,NumVotes,OutOfDate FROM PACKAGES WHERE...

The only thing this patch does is to let you choose what fields you want to get when searching, instead of "Name,ID" (though they are the default to keep backwards compatibility)

> What is the expected behavior?
> This is a vague statement.

> Let me try to be psychic for a minute, since what you are saying isn't really clear at all...

I am not english native, i hope you get more clear understing now.

> Are you saying that you want to see the *same information* as you see in the web interface when you get search results?
> The (Location,Category,Name,Votes,Description,Maintainer) tuple?

> Now *that* is a feature request I could see as reasonable.

Ok, you can take this request if you don't want my patch. It fits my needs. I was simply trying to make something more flexible.

> Note: I probably wouldn't want to see any join logic (foreign table data) returned in the initial result set though (or at least no complex join data). I don't rememberoffhand what is being done to generate the aur web search result data.

If you tell me where i can find the database structure, I can check what logic lives behind the table/view Packages.

PS: Your answer surprised me a bit, because I felt you criticized my patch without knowing what it does and its consecuences. If my previous post offended you it was completely unnintentional. I am not a native english speaker, so I have a limited empathy when i write in this language.
Comment by eliott (cactus) - Monday, 26 May 2008, 06:56 GMT
what?
I looked at the patch, and gave an initial response.

*Then* you proceeded to provide a long description, which actually confused me as to what you were asking for.
Sorry if you took the initial response as criticism, but that certainly isn't my fault.
Comment by pajaro (pajaro) - Monday, 26 May 2008, 09:49 GMT
Ok, sorry.

Loading...