getStatusHistory question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

getStatusHistory question

Owens, Mark
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.getConnectionStatusHistory(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

Reply | Threaded
Open this post in threaded view
|

Re: getStatusHistory question

Mark Payne
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 <[hidden email]> 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.getConnectionStatusHistory(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
>

Reply | Threaded
Open this post in threaded view
|

RE: getStatusHistory question

Owens, Mark
Thanks Mark,
I'll take a go at updating it to handle the parameters.
Thanks,
Mark


-----Original Message-----
From: Mark Payne <[hidden email]>
Sent: Wednesday, June 26, 2019 9:08 AM
To: [hidden email]
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 <[hidden email]> 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
>