Thanks Mark,
I'll take a go at updating it to handle the parameters.
Thanks,
Mark
-----Original Message-----
From: Mark Payne <marka...@hotmail.com>
Sent: Wednesday, June 26, 2019 9:08 AM
To: dev@nifi.apache.org
Subject: Re: getStatusHistory question
Mark,
I don't think that it was intentional. The interface was created with the idea
that we will have a persistent implementation, as well, and that will hold a
lot more data, so the start/end will be very important. For the Volatile case
it was probably just overlooked and never noticed because typically it's
configured to hold no more than 24 hours' worth of data.
Would be happy to review a PR if you do update the code.
Thanks
-Mark
> On Jun 26, 2019, at 8:49 AM, Owens, Mark <jmow...@evoforge.org> wrote:
>
> Hi,
>
> I'm working on a task that requires retrieving some StatusHistory objects. I
> have a question concerning the getConnectionStatusHistory method in
> FlowController.
>
> The method takes parameters for a start date, end date, and preferred data
> points returned. The call chain then goes as follows:
>
> FlowController.java:
>
> public StatusHistoryDTO getConnectionStatusHistory(final String connectionId,
> final Date startTime, final Date endTime, final int preferredDataPoints) {
> return
> StatusHistoryUtil.createStatusHistoryDTO(componentStatusRepository.get
> ConnectionStatusHistory(connectionId, startTime, endTime,
> preferredDataPoints)); }
>
> The call to componentStatusRepository.getConnectionStatusHistory(..)
> passes to VolatileComponentStatusRepository.java
>
> @Override
> public StatusHistory getConnectionStatusHistory(final String connectionId,
> final Date start, final Date end, final int preferredDataPoints) {
> return getStatusHistory(connectionId, true,
> DEFAULT_CONNECTION_METRICS); }
>
> But at this point the start/end/preferred parameters are ignored as
> getStatusHistory is called without making any use of them.
>
> I had provided the filter parameters since I was only interested in a subset
> of objects. Am I missing something in this call chain? If not, is the
> dropping of these parameters intentional but undocumented? If not intentional
> I can update the code to honor these parameters, but I wanted to see if the
> ignoring of the parameters should have been expected. If it is, perhaps some
> comment in the code indicating that the parameters will be ignored would be
> helpful in preventing one from thinking they are going to be utilized.
>
> Thanks,
> Mark
>
