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

[new page] open feature requests #64

Closed
jackzampolin opened this issue Dec 9, 2015 · 5 comments
Closed

[new page] open feature requests #64

jackzampolin opened this issue Dec 9, 2015 · 5 comments

Comments

@jackzampolin
Copy link
Contributor

Originally: https://github.com/influxdb/influxdb.com/issues/234

Let's put up a page of the larger feature requests (timezone support, month/year support, custom functions, multiple mount points, etc) so that they are discoverable, and so that we can make some comments about them all in one place. It will help the community understand what's on the eventual roadmap, what's open for debate, and what's not going to be considered until 2.x or later.

@rkuchan
Copy link
Contributor

rkuchan commented Jan 5, 2016

@beckettsean, would it be good enough to link to the issues tagged with rfc on GitHub or does it need a full doc?

@beckettsean
Copy link
Contributor

@rkuchan this is actually different from the rfc issues. It's less about "what do you think we should do with these?" which is the rfc label, and more about "you probably expect the database to do these, but it doesn't yet. Here are the relevant issues so you can follow them without having to search the 450 open issues for them, or emailing us about it."

I think it should be a simple list of the 10-15 most requested features that aren't yet implemented. I'll do my best to add representative links here soon.

@beckettsean
Copy link
Contributor

Here is my list with a quick runthrough of the open issues. It's a good start, and might need to be edited down a bit. If we can logically group them it might be clearer with a long list.

@jufemaiz
Copy link

Another one which I think would be worthwhile dealing with is falling edge / trailing edge for data.

Accumulators (for instance) are generally timestamped on the falling edge of the period in which they've counted values for, yet this causes problems at transitions of time (e.g. 00:00 with a fifteen minute periodicity would encompass data values from 23:45 to 00:00 but the previous day).

@beckettsean
Copy link
Contributor

It's a good idea, but too much work to maintain.

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

No branches or pull requests

4 participants