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, 5 Jun 2008 14:47:51 -0700
Alright I understand. I hadn't thought about caching. So maybe the extra> On 6/5/08, Simo Leone <simo@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.
parameter should just enable full info retrieval on searches.