[Buildbot-devel] Generic implementation for paging and sort functionality in data api

[Pierre Tardy]

On Wed, Aug 1, 2012 at 1:42 PM, Dustin J. Mitchell <djmitche at gmail.com>wrote:

> On Wed, Aug 1, 2012 at 2:17 AM, Naveen Kumar <naveen.iitm90 at gmail.com>
> wrote:
> >>  It may be necessary to
> >> distinguish "details" endpoints (one item) from "list" endpoints (a
> >> list of items) by having different parent classes for them.
> >
> > This is a considerable change. This can be done later?
>
> It depends on how things work out in implementing it.  It will
> probably be easier to do this than to avoid it.
>
> And yes, data extraction will still take place in each Endpoint class,
> since they'll each need to call different DB methods in different
> ways.
>

Dustin,
We are talking about two features for "list" enpoints: range, and sort.
Those very generically translate into SQL's LIMIT + OFFSET (not sure about
offset) and  ORDERBY.

Each data api call is supposed to eventually go ahead and make a big join
sql query.

So question is where could we put a generic method somewhere in a db base
class, that would decorate an sqlalchemy query with appropriate  LIMIT and
ORDERBY.
I think this could work for most case, and of course will need to be
tweaked for more complicated queries.

So Naveen,
After learning dojo, twisted, I'm afraid you'll need to also learn
sqlalchemy, in order to achieve your goal. Those are all very interesting
techs, that are very much worth it.

Dont hesitate to try the (relatively) simple way first, as dustin suggested:
- Split endpoints in two types. List will accept and validate range= and
orderby= args.
- implement it for the two endpoints already existing: changes, and master
So that you can experiment with sqlalchemy, then we can sit, and understand
how this can be done more generically.

Good luck ;-)
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20120801/74009713/attachment.html>