[aur-dev] [PATCH] Extended JSON query method

[Francesc Ortiz]

eliott,

there are 2 proposed solutions:
a) return all fields when searching.
b) add a way to get all fields when you search.

choose one or propose an alternate solution.


On Thu, Jun 5, 2008 at 11:56 PM, Loui <louipc.ist at gmail.com> wrote:

> On Thu, 5 Jun 2008 14:47:51 -0700
> eliott <eliott at cactuswax.net> wrote:
>
> > On 6/5/08, Simo Leone <simo at archlinux.org> wrote:
> > > On Thu, Jun 05, 2008 at 11:14:22AM -0400, Loui wrote:
> > >  > This is a different patch from the one in the bug tracker
> > >  > (implementation looks a little cleaner). Do you have the same qualms
> > >  > about this one? I think there should be a way of specifying more
> info
> > >  > in the search. What's good about this method is that it will only
> > >  > return what's needed, no more, no less.
> > >  >
> > >
> > > I think it adds needless complexity, why not just return all data on
> the
> > >  specified packages?
> >
> > That was my argument in the bugtracker ticket also.
> >
> > Making on the fly decisions about what to return for simple select
> queries is:
> > 1) more expensive than just returning all fields
> > 2) makes it harder for the mysql query cacher to cache it
> > 3) would make it harder for any potential future memcache layer to cache
> it
> >
> > And this appears at a first look to be doing the same thing as the
> > other ticket, that is: passing in which fields the client wants back,
> > and selecting only those fields from the table, then returning them to
> > the client.
> >
> > I don't see how it is a different implementation. Things just got
> > moved around a bit.
>
> Alright I understand. I hadn't thought about caching. So maybe the extra
> parameter should just enable full info retrieval on searches.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/aur-dev/attachments/20080606/dff5c964/attachment.htm>