On 10/14/11 1:38 AM, Kristian Waagan wrote:
On 10/13/11 02:47 PM, Rick Hillegas wrote:
On 10/13/11 3:12 AM, Kristian Waagan wrote:
On 10/13/11 12:48 AM, Kathey Marsden wrote:
FYI, I filed this IFRA issue which has some impact on the Derby
Jira VTI in our demos.
I suppose the demo will still work but now Jira export is limited
to 1000 issues. Is a DERBY issue in order as well?
Working around that limit is possible in this case [1] - the
question is if we want to do that?
If people are using this demo extensively as their own private
"Derby JIRA cache", I think some effort should be invested into
writing something that imposes less load on the ASF JIRA instance.
Writing something solid here may require quite a bit of effort.
Without having given this extensive thought, I think parsing emails
as suggested on infra is the kindest option. This would probably
suit committers well.
Maybe the activity stream (as an RSS feed) could be used too, but in
that case it may be harder to make sure no updates are missed.
A third option is to use the SOAP API. One has to be able to define
a suitable search (for instance 'give me all updates on Derby from
date X to date Y'), but I suspect you'd have to download all the
issue information instead of just what changed in that period. The
upside with this approach compared to the RSS one, is that you
decide when you want to update your copy.
Now that we (by which I mean Kristian) know how to use the SOAP API,
it may be possible to write a restricted vti that wraps the SOAP API.
I believe that the existing vti is used to dramatically reduce the
set of issues you have to look at by applying restrictions which
cannot be expressed in the JIRA gui.
What are examples of such restrictions?
Hi Kristian,
Here is a sample query which uses the existing jira xml vti (from
http://wiki.apache.org/db-derby/HowToRunJiraVtiReports):
select s."key", s."assignee", s."updated" , s."title"
from table( "apacheVanillaJiraReport"(
'file:///kmarsden/projects/jirareports/all_JIRA_ISSUES.xml' ) ) s where
"resolution" = 'Unresolved' and "assignee" != 'Unassigned' and NOT
"updated" like '%2008%' order by "assignee";
There are two interesting things about this query:
1) Projection (fancy term for "SELECT list")- The SELECT list is just a
few of the columns in the vti. That is, the width of the query result is
considerably narrower than the full width of the vti.
2) Restriction (fancy term for pieces of the WHERE clause) - A couple
terms in the WHERE clause could be pushed into the Store if the query
were directed against a Derby table rather than a vti. These terms
reduce the length of the result set coming back to the SQL interpreter.
These terms are:
"resolution" = 'Unresolved'
"assignee" != 'Unassigned'
If the query were issued against a restricted vti which wrapped the SOAP
api, then the projection and the restriction could be pushed into the
vti. That is, Derby would tell the vti to fetch only 4 columns and to
throw away any rows which didn't match the two WHERE clause terms above.
Presumably, this information could be passed through the SOAP api to
limit the width and length of the result set being requested from JIRA.
Thanks,
-Rick
If I understand correctly, those restrictions can be expressed in the
SOAP API. By pushing those restrictions into the SOAP query, we would
dramatically reduce the data set being requested from JIRA in the
first place. That should satisfy the objections of the INFRA group.
I'm still a little puzzled by how this demo/tool is being used.
There's a big difference if we go from parsing a local XML file
multiple times, to accessing the JIRA instance through the SOAP API on
every invocation (for instance as you are refining your SQL query).
FYI, pulling in SOAP requires some extra libraries. A tool as
described above would probably be a Maven project like the SOAP client
used to generate parts of the release notes.
Regards,
