-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Wire up drop series statement #1422
Comments
After looking into this issue, I have several questions that I could use some feedback on. Let us start with the example data for insert that we will use in the following discussions: {
"database":"foo",
"retentionPolicy":"bar",
"points":[
{
"name":"cpu",
"tags":{
"host":"server01"
},
"timestamp":"2015-01-26T22:01:11.703Z",
"values":{
"value":".954"
}
},
{
"name":"cpu",
"tags":{
"host":"server02"
},
"timestamp":"2015-01-26T22:01:11.704Z",
"values":{
"value":".854"
}
}
]
} This will create two series, effectively:
If I query the current system, I get: > show series
name tags host
---- ---- ----
cpu server01
cpu server02 What I suggest we get is: > show series
id name host
--- ---- ----
1 cpu server01
2 cpu server02 This would then allow us to do: DROP SERIES 1 As well as issue a delete like this: DELETE SERIES cpu WHERE host=server01 |
@corylanou all of that is correct. The current |
I think the current syntax supported by the parser is wrong...
Are these the only two we need?...
In the latter of the two, both the from-clause and where-clause would be optional? |
In general, My preference is both |
|
@pauldix do you have a preference on this? Want to just get consensus before making the changes. I agree that we have a fairly different scenario here, and considering we really are "drop"ing an entity, that @dgnorton also, just to clarify, should we only support one way of it? Or do you still propose we support both as you outlined above: DROP SERIES <id>
DROP SERIES FROM <measurement> WHERE <expr> |
I favor supporting both |
The commands suggested by @dgnorton make sense to me. |
@corylanou what you have in your last comment is correct. Support dropping a specific series id or dropping all series from a measurement matching a where clause. Further the the dimensions that show up in the where clause should only be tag keys. You shouldn't be able to have field names or time in the where clause of a drop series. For |
No description provided.
The text was updated successfully, but these errors were encountered: