But if you can express your query using JQL, why not go directly to
JIRA?
I think that the problem is that there are some queries (particularly
those involving NOT) which can't be constructed using the existing
JIRA gui. You can say "I want all issues with the following fields
turned on" but you can't say "I want all issues with the following
field NOT turned on".
Thanks,
-Rick
I see the point of caching and dataset rip-offs (i.e. you populate a
table and continue to refine the results/searches locally), are there
other use-cases where people think they would prefer Derby+VTI over
JIRA+JQL?
I know of a couple of tools where it is important to be able to do
queries joining JIRA data with local private DERBY tables. A VTI with
JQL would be nice for that sort of thing, but NOT is a requirement and
I actually still think might actually pull more data over time with
the number of queries than just creating the cache table periodically.
One of these very old tools just dumps the data from Jira into a
JIRA_ISSUES table and does queries. I think that ancient app will just
have to become smarter about updating the data in the table
incrementally to maintain the same functionality.
Personal problems aside, I don't know how much the JIRA VTI demo or any
kind of JIRA data download and interface to Derby is being used by the
user community. I have used this sort of thing for analyzing issues
for backport and generating metrics. I know they can be useful to
manage support and development work, joining private customer data with
the public data in Jira. I could imagine it might be useful to other
development groups in the same capacity, so the Jira VTI might be a good
demo for that reason, but my gut feeling is that demo is not used that
often (of course could totally be wrong).
Kathey
