2009/9/17 Loui Chang <louipc.ist@gmail.com>:
On Thu 17 Sep 2009 10:34 +0800, Gergely Imreh wrote:
2009/9/17 Loui Chang <louipc.ist@gmail.com>:
On Mon 14 Sep 2009 22:46 +0800, Gergely Imreh wrote:
The following patch adds the Orphan field to the aurjson output. For username we would need to hit the database once more (maybe, have to think more SQL for that), but the Orphan-ness is quite straightforward to evaluate. So let's just do that first.
This patch, however, might clash with one patch I sent in a few days ago [1], since that one hasn't been applied to the repo, yet. Anyway, neither of those are hard to see where they should go...
Any comments?
@@ -139,6 +140,8 @@ class AurJSON { if ( $result && (mysql_num_rows($result) > 0) ) { $row = mysql_fetch_assoc($result); mysql_free_result($result); + $row['Orphan'] = ($row['MaintainerUID'] == "0" ? "1" : "0"); + unset($row['MaintainerUID']);
Just leaving MaintainerUID as-is here should be good enough I think. I'll push that if you want to resubmit. Thanks.
The reason I have the "Orphan" and not the "MaintainerUID", because from the website it is not possible to connect the MaintainerUID and the username, and I'm not aware of any way one can search for the username or packages using MaintainerUID. That makes this number pretty meaningless except for AUR internal usage.
Also, having an "Orphan" value is completely self-explanatory (as are the OutOfDate and all other fields...) - one can just look at the json output for the very first time in their life and see what means what. The "If MaintainerUID is 0 then it is an orphan package, if whatever
0 then someone maintains it" is a needed explanation beyond the aurjson output.
If you want to change something, then remove the removal of the MaintainerUID (for some usage I might not thing of right now). The "orphan" field should stay in my opinion.
I understand how this might be useful for the average user, but they'll most likely never see it. It only needs to be understood once by the application developer, and it's documented - in the code heh.
It's inefficient to add more processing just for aesthetic purposes.
So let's think about adding something useful.
You can get usernames with one query:
select Name,Username from Packages left join Users on (Packages.MaintainerUID = Users.ID) where DummyPkg = 0 limit 10;
I just tested this against plain MaintainerUID. That yields a performance hit of about 200 milliseconds for 15828 packages, which doesn't seem too bad.
I'm testing on a slow system anyways.
So I think it may be alright to just grab Username. Orphaned packages will have a NULL Username. This should be added to both info and search functions.
I personally don't think that one should have to read the AUR codebase to be able to interpret the rpc.php output. It is simple enough that it should be self explanatory - just like it was before this conversation started. And don't really feel it's an aesthetic issue but a purely logical. Ways to know if a package is an orphan: 1st version: "Are you an orphan? yes / no" 2nd version: "Who's your daddy? JohnDoe / NULL" Just because it's software mainly talking to software, it still can be clear. Also, I'm a bit puzzled by the objection to a single line of $row['Orphan'] = ($row['MaintainerUID'] == "0" ? "1" : "0"); which was countered with a suggestion of a full database re-query. Would THAT really take that much shorter? Have to do some checks in my test aur install to wrap my head around it. Would have thought that AUR has a lot of other inefficiencies that can be improved (pretty sure that my PKGBUILD parsing routines are no exceptions), before we worry about a single "if". Having said all this, I can see the point of returning the username / "orphan" (or username / ""?) instead of Orphan logical variable. I wouldn't have chosen it myself originally because of the extra database hit, but now it seems to be more in line with the behaviour of the web interface. Loui, do you want to write that changes, or should I send an updated patch? I don't mind either way, glad to get the job done. :) Cheers, Greg