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 <[EMAIL PROTECTED]> wrote: > On Thu, 5 Jun 2008 14:47:51 -0700 > eliott <[EMAIL PROTECTED]> wrote: > > > On 6/5/08, Simo Leone <[EMAIL PROTECTED]> 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. > >