[aur-dev] AurJson - orphan packages

[Loui Chang]

On Thu 17 Sep 2009 10:34 +0800, Gergely Imreh wrote:
> 2009/9/17 Loui Chang <louipc.ist at 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.