Modify

Opened 7 years ago

Last modified 5 months ago

#1650 reopened enhancement

extend ticket.query() to return any field

Reported by: stp Owned by: athomas
Priority: normal Component: XmlRpcPlugin
Severity: normal Keywords: ticket query
Cc: mladen@…, nick.piper@…, cauliflower.kan@… Trac Release: 0.10

Description (last modified by athomas)

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.

Attachments (1)

changeset_4148.diff (4.9 KB) - added by pipern 2 years ago.
Patch to implement ticket.queryTickets() which can return column data

Download all attachments as: .zip

Change History (14)

comment:1 Changed 7 years ago by 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?

comment:2 Changed 7 years ago by stp

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.

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by athomas

  • Description modified (diff)
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:5 Changed 7 years ago by mika

  • Cc mladen@… added
  • Keywords ticket query added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:6 Changed 7 years ago by anonymous

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:7 Changed 7 years ago by anonymous

  • Component changed from XmlRpcPlugin to WikiPrivatePatch

comment:8 Changed 7 years ago by osimons

  • Component changed from WikiPrivatePatch to XmlRpcPlugin
  • Resolution fixed deleted
  • Status changed from closed to reopened

Please don't mess with tickets.

comment:9 Changed 3 years ago by osimons

#9550 closed as duplicate.

comment:10 Changed 2 years ago by 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]

comment:11 Changed 2 years ago by anonymous

  • Cc nick.piper@… added

Changed 2 years ago by pipern

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

comment:12 Changed 7 months ago by 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?

comment:13 Changed 5 months ago by cauly

  • Cc cauliflower.kan@… added

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.

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.