[aur-dev] AurJson - orphan packages

[Dan McGee]

On Wed, Sep 16, 2009 at 10:43 PM, Loui Chang <louipc.ist at gmail.com> wrote:
> 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.

OMG, query benchmarking? I've never seen this in the AUR before. :P

I would just do it right and return a maintainer name. Worry about
performance later; there really is little to no penalty here for this.
I already told you one query that needs optimizing the other day that
is much more prevalent than this one.

-Dan