Ha, was thinking about that too. I see a ticket_change table in the database. So I generate the data from that table at the beginning and can rely on the above method for future changes. I am not sure if every change is saved in that table. Can you confirm this for me ?
On Mon, Apr 29, 2013 at 10:20 PM, Gary Martin <[email protected]>wrote: > 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> >>>>> <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> >>>>> <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.**apa**che.org/jira/browse/COMDEV-****94<http://apache.org/jira/browse/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<http** >>>>>> s://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 >>>>>> >>>>>> >>>>>> >
