Delete statement ignores a retention policy

[alex-vv]

Bug report

Delete statement ignores a specified retention policy and deletes data across all retention policies.

System info: InfluxDB 1.0 beta3, InfluxDB nightly (1.1.0~n201607220800) Ubuntu 14.04

Steps to reproduce:

# create database
curl http://localhost:8086/query --data-urlencode "q=CREATE DATABASE mydb"

# create non-default retention policy myrp
curl http://localhost:8086/query --data-urlencode "q=CREATE RETENTION POLICY myrp ON mydb DURATION 365d REPLICATION 1"

# write data to default rp
curl -X POST "http://localhost:8086/write?db=mydb" --data-binary "cpu,region=useast,host=server_1,service=redis value=61"

# write data to myrp
curl -X POST "http://localhost:8086/write?db=mydb&rp=myrp" --data-binary "cpu,region=useast,host=server_1,service=redis value=62"

# delete data from myrp
curl "http://localhost:8086/query?db=mydb" --data-urlencode 'q=DELETE FROM myrp.cpu'
# alternatively tried
# curl "http://localhost:8086/query?db=mydb&rp=myrp" --data-urlencode 'q=DELETE FROM myrp.cpu'

# Query default rp
# Bug: expected it to return data, but no data comes back.
curl -G "http://localhost:8086/query?db=mydb" --data-urlencode 'q=SELECT * from cpu'

Expected behavior: Data deleted only from myrp retention policy

Actual behavior: Data deleted in all retention policies

[jsternberg]

Looking at the docs, I think this is the intended behavior. @beckettsean thoughts?

http://docs.influxdata.com/influxdb/v0.13/query_language/database_management/#delete-series-with-delete

It seems to me like the behavior that he's saying seems more appropriate, but it would potentially be a breaking change.

[beckettsean]

@jsternberg I agree the behavior is currently as intended, but also that it's not intuitive. Sometimes RPs are logically separate (all writes, all SELECT queries), and sometimes they aren't (SHOW and DELETE queries). I think we should pick one and get consistent, but that's a larger project than just this bug report.

[jwilder]

@we should either:

1. Return an error if an RP is specified since since user would expect only data deleted from that RP, but we actually delete everything.
2. Change the behavior to respect the RP.

I think 2 is preferable, but 1 might be an easier short term fix.

[beckettsean]

@jwilder I agree with implementing #1 for the 1.1 release.

Perhaps we can get a project for 1.2 where SHOW and DELETE queries treat RPs as logically separate, just like writes and SELECT queries?

[corylanou]

@jwilder I need a final answer on the direction for resolving this issue. I can attempt 2, but if that involves a really big change, I can simply do 1 as an interim and punt 2 to a future milestone. Thoughts?

[jwilder]

@corylanou See if you can get 2. If it's pretty involved, let's at least get 1 in.