Community
Participate
Working Groups
The Collector concept in the query API is there to allow clients to do further scoping/checking of query results when an object matches a query. I'm wondering if Collector.accept should have a progress monitor argument. There is one passed into the query, and perhaps it could be passed through to the perform/accept? My case is admittedly a bit weird. I have a collector that is actually performing a secondary query on the result of the original query. And so it has no progress monitor to pass to its secondary query. The concrete example is that I am querying a metadata repository manager for all public repos, and as I accept each repo, I load it and get all of its categories.
Your usage seems a bit odd. Couldn't you just perform two queries - one query to get the list of repositories, and then a second query on each of the repositories to get the categories? If a collector were to do really long running work, the query would have no way to know how long it is... how many child ticks do I allocate to the collector if it may be just adding an item to a list, or it may be performing arbitrary long running work?
Because of the call chain/code structure, performing two separate queries wasn't going to work. But...I ended up restructuring some model elements for other reasons, and in the end, this scenario wasn't needed. (I meant to update this bug to let you know...) So if you think it doesn't really make sense, you can close this.
Ok, I'd like to keep this API as simple as possible, and adding progress monitors for the rare case it may be needed just creates work for all callers.
