[aur-dev] [PATCH] Extended JSON query method
From: Sylvester Johansson
On Tue, 3 Jun 2008 20:25:33 +0200
Sylvester Johansson
On 6/3/08, Loui
On Tue, 3 Jun 2008 20:25:33 +0200 Sylvester Johansson
wrote: Hey Sylvester. I think I like this method better than the other. Could you fix the indentation (especially in function query), put a more descriptive commit message, and resubmit? Thanks.
I already outlined on the bugtracker why I thought this wasn't exactly a great idea, as it was implemented. oh well.
On 6/3/08, Loui
wrote: On Tue, 3 Jun 2008 20:25:33 +0200 Sylvester Johansson
wrote: Hey Sylvester. I think I like this method better than the other. Could you fix the indentation (especially in function query), put a more descriptive commit message, and resubmit? Thanks.
I already outlined on the bugtracker why I thought this wasn't exactly a great idea, as it was implemented. oh well.
This is a different implementation than the one discussed on the bugtracker. The difference is that with this, you can specify on the client-side what fields the json result should contain, while the other was set server-side. There is no sql joins going on, so it would be a
On Thu, Jun 5, 2008 at 2:14 AM, eliott
On Wed, 4 Jun 2008 17:14:35 -0700
eliott
On 6/3/08, Loui
wrote: On Tue, 3 Jun 2008 20:25:33 +0200 Sylvester Johansson
wrote: Hey Sylvester. I think I like this method better than the other. Could you fix the indentation (especially in function query), put a more descriptive commit message, and resubmit? Thanks.
I already outlined on the bugtracker why I thought this wasn't exactly a great idea, as it was implemented. oh well.
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 guess what we could really use are examples of it's usage and potential abuse. At least with this method the server won't be hit as hard as if the client did the search and requested info for every single search result. Maybe we can patch the behaviour later on when the implications are clearer from real life testing eh? Heh, it's obviously a highly requested feature by AUR application devs. I would have written a patch like this myself. :P
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?
I guess what we could really use are examples of it's usage and potential abuse. At least with this method the server won't be hit as hard as if the client did the search and requested info for every single search result.
Bandwidth is cheap, it's mostly looking up on one table for package info, it's not really a performance hit to return more info. -S
On 6/5/08, Simo Leone
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.
On Thu, 5 Jun 2008 14:47:51 -0700
eliott
On 6/5/08, Simo Leone
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.
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
On Thu, 5 Jun 2008 14:47:51 -0700 eliott
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
On 6/5/08, Simo Leone
wrote: 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.
On 6/6/08, 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.
I thought I had already stated that I felt returning either all, or probably more optimally returning a reasonable hard-coded subset of fields, was a good idea. I only found fault with the on the fly determination of which fields to return. However, the AUR is now in the capable hands of Simo, Loui, and Callan. The ultimate decision now lay with them. This will be my last post on this mailing list.
participants (5)
-
eliott
-
Francesc Ortiz
-
Loui
-
Simo Leone
-
Sylvester Johansson