Well, your method might well be quicker but strictly speaking you would
also want to be gathering historical data from an upgrade to a trac
database or an older version of bloodhound. Even if we only consider new
databases, if the change listener was the only method, each time we
create a new times series report we will only be able to look at future
data.
The other approach is just to do the query when a request for it is
sent. Caching or permanently storing the results may be premature
optimisation and we may not want that for every report anyway.
Cheers,
Gary
On 29/04/13 17:22, Shiva Teja wrote:
Hi Gary,
Yeah, sorry, I should I have been a bit more clear. I've been thinking
about it. Currently I am trying to optimize it using ITicketChangeListener.
Whenever there's a change, I store either in the db(or a file?) in such a
way that generating these reports are optimized. All the reports you are
talking about, are doable using ITicketChageListener, combined with
TracCronPlugin. What do you think?
Regards,
Shiva Teja.
On Mon, Apr 29, 2013 at 9:39 PM, Gary Martin <[email protected]>wrote:
Hi,
It might be worth noting that periodic creation of these reports is not
the primary aim, unless of course I am missing something. The way I
interpret the core idea of the ticket is to provide users with a simple way
of producing reports which can show another query as a function of time,
where the timeslices within which to bin the data are configurable in size.
As that would only give us a single column of data, it would also be good
to be able to choose an additional column from the original query to group
by in order to show comparative data. So we would then be able to get a
table of data showing stuff like:
* the number of tickets that are created and resolved for a given
product per day
* the number of tickets that are open and closed for a given product
on each day
* the number of tickets assigned to or resolved by a particular user
per day
and many other variations.
For the moment these reports could be regenerated each time it is
requested (this could be optimised later if it seems worthwhile). If we
have that kind of base then, beyond that, there are lots of directions you
could go to build into a larger project if this doesn't seem a big enough
project. This could include the periodic report creation or notification,
or perhaps plotting the data. It would be interesting to hear what else you
can come up with though.
Cheers,
Gary
On 29/04/13 16:06, Pranay B. wrote:
Thanks Mr. Teja! This is really helpful.
Thank you.
~Pranay B.
'Science may set limits to knowledge, but should not set limits to
imagination.'
- Bertrand Russell
*
*
*
*
On 29 April 2013 08:02, Shiva Teja <[email protected]> wrote:
Hi Pranay,
Nothing from my side. I was planning to do it with TracCronPlugin[1] and
run queries periodically to generate reports using the Database API[2].
But
I haven't discussed it with them yet. So wait for someone to reply. Good
Luck :)
[1]
http://trac-hacks.org/wiki/**TracCronPlugin<http://trac-hacks.org/wiki/TracCronPlugin>
[2]
http://trac.edgewall.org/wiki/**TracDev/DatabaseApi<http://trac.edgewall.org/wiki/TracDev/DatabaseApi>
Cheers,
Shiva Teja
On Mon, Apr 29, 2013 at 6:06 AM, Pranay B Sodre <[email protected]
wrote:
Hello Everyone- How are you? A quick question for you.
Does anyone have existing documents at attempts for
Apache Bloodhound "Add time series" report--
COMDEV-94<https://issues.**apache.org/jira/browse/COMDEV-**94<https://issues.apache.org/jira/browse/COMDEV-94>
The original ticket number is Ticket
#489<https://issues.apache.**org/bloodhound/ticket/489<https://issues.apache.org/bloodhound/ticket/489>
It would be helpful to get a sense of what has already
been developed in the community (even if incomplete,
it would help to get a sense of the ticket attempt and scope.)
Mr./Ms. Olemac or Mr. Shiva- If you have any previous
attempts or advice, please help. Thank you.
~ Pranay B.
"Logic will get you from A to B. Imagination will take you everywhere."
-Albert Einstein
