extend ticket.query() to return any field

[Steffen Pingel]

Currently ticket.query() returns an array with the id of matching tickets only. Having an additional parameter that takes a list of field names that are also returned would be a very useful addition to avoid multiple server round trips to retrieve the actual ticket information:

ticket.query('status!=closed', [ 'id', 'summary' ])

That would return: [[id => 'id', summary => '...' ], ...]

Since this breaks backwards compatibility adding an API call queryFields() instead modifying query() might be prefereable.

[osimons]

Using MultiCall() you can do what you want using one HTTP request - see example in the documentation on the XmlRpcPlugin wiki page.

It will return all fields of the tickets in the result, but it will do so in a fraction of the time compared to using many rountrips. We have done some testing with multicall that first fetch list or do query, and the return the details of each in result - for both ticket and wiki. For a 'normal' query (whatever that is...) the difference is going from 20-30 seconds to 1-2 seconds total... Pretty much like most other single calls, really. Tested both using Python standard lib, and some .Net library that also supported multicall - which I think most libraries will do.

Your proposed method looks nice, but I do not think there is a drive to add to more specialised methods to the api if there are good working solutions using MultiCall() - the payload sent over the network is not substantially larger (not much to save there), nor much difference in processing this on the server vs. the client, and it is really a more flexible approach.

Could you try MultiCall(), and then re-evaluate if your suggested feature is still needed?

[Steffen Pingel]

This would at least require two calls. One call to retrieve the list of ticket ids and a second call to get the desired fields / tickets. On the Trac side that would duplicate the database query since the first call already retrieves all required information from the database but only returns the id.

Therefore an additional API call for specifying a list of tickets would be the best solution in terms of server as well as client performance.

[osimons]

Well, tried a MultiCall() against trac-hacks with a query returning many tickets (roughly 100 out of <2000). It took approx. 5-15 seconds to get all results back - tried the same query a few times with different times each time (randomly higher and lower depending on other server activity I suppose).

And yes, you are right - I used two calls in that timeperiod; retrieving IDs, and asking for them all at once using multicall.

Trying a shorter query (only a handful of results), the time was quite consistently in the 4-5 seconds range.

[Alec Thomas]

I'm not going to implement this for the reasons stated by osimons. I don't think it's a huge deal to require two round trips, and I'd prefer to keep the API as simple as possible.