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.

[mika]

I think this is a great idea and I'd like to just mention my reasons here.

1. When doing a query for a list of tickets you would hardly ever just want id's. you would want at least subjects as well, although I would recommend all main attributes like owner, assigned, dates, milestons - pretty much all but description, keywords, and cc since they would not potentially be single word responses.
2. When I did what osimons did above my get multicall took 1 minute 30 seconds. I'm in South Africa on a DSL line. I'm using the C# xmlrpc library which would take the results and would probably spend some time converting them to arrays/stucts etc... Still this is waay too long for a query with 100 items. (This is from trac hacks)
3. I also tested with a result of 300 tickets. This is a bit more than anyone would usually get (and I would probably limit it to 100 anyway) but the result was 50,000+ lines of XML. I'm not sure what the total byte size was, but this is ridiculous just to get basic data for a list of tickets and not the actual details.

My suggestion, please could you maybe add this as a separate call, maybe ticket.queryExtended or something which would either take a list of attributes needed or just return the ones I mentioned in point 1.

[osimons]

Please don't mess with tickets.

[osimons]

#9550 closed as duplicate.

[pipern]

This is the implementation which we did locally.

The query string format already has a syntax for columns:

status!=closed&col=id|summary|owner

so we decided we should continue to use this. However, it means (as there is already a default set of columns for queries) that if we want to return the same data as before, we have to use a different function name. So I've introduced queryTickets method that can return column data now too:

> call queryTickets status!=closed&col=id|created|summary|owner
>> [[1, '2011-09-14 10:22:28', '234', 'groupinfra\\pipern'], [2, '2011-09-14 12:20:57', 'defect 1', 'groupinfra\\maltessona'], [3, '2011-09-14 12:24:06', 'asdfasdf', '']]
> call query status!=closed&col=id|created|summary|owner
>> [1, 2, 3]

[pipern]

Patch to implement ticket.queryTickets() which can return column data

[anonymous]

Can we get this added to the main release as well? I don't think the Zen of trac is diminished by adding a query that is usable.

As others pointed out returning of the IDs only is never enough (at least I cannot think of a single scenario in which the caller needs only the IDs). In other words if the two things (IDs and some ticket properties) are always used together wouldn't it be even more simplistic to have a single call to retrieve them together and increasing the Zen at the same time?

[Cauly]

Hope to see ticket.queryTickets() in main stream too.

Sometimes I need only the summary of querying tickets, so a multicast returned too much infomation for me(I have 20+ custom fields and some of them have pretty big data). Now I have to do a query, then use ticket.get() one by one and show a progress bar to user, stopping them from throwing something in my face.