Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose maxDataPoints to storage finders #159

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mbell697
Copy link
Contributor

@mbell697 mbell697 commented Mar 5, 2016

This exposes maxDataPoints to custom finders/readers so they may pre-compute rollups at the storage layer. Fixes the primary request of #109.

This doesn't implement another feature mentioned in that issue: to pass the consolidation function defined via consolidateBy to the finder/reader. That could be an area of improvement in the future but I can't dream up an application for it at the moment.

The implementation requires an attr flag be set on the finder/reader to avoid breaking backward compatibility with existing plugins.

There are a few related code paths in here that don't look to have great test coverage so I would hold off on merging this until I can do a bit of end to end testing with a finder/reader implementation that supports it, particularly with multi-fetch. I'll be testing this in the day or two.

Copy link
Owner

@brutasse brutasse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! A minor change would be nice, to make it slightly simpler to write compatible finders.

if hasattr(self.reader, '__aggregating__'):
return self.reader.fetch(startTime, endTime, maxDataPoints)
else:
return self.reader.fetch(startTime, endTime)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use inspect.signature (or getargspec on Python 2) to "guess" the ability of .fetch to accept maxDataPoints instead of having to rely on a magic attribute?

Or do a try… except TypeError but it would be less elegant…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants