search

BTrDB / btrdb-server

Berkeley Tree Database (BTrDB) server
http://btrdb.io
MIT License
909 stars 66 forks source link

Possible bug (or API suggestion) for nearest #56

Closed samkumar closed 6 years ago

samkumar commented 6 years ago

I was noticing some weird results with the bracket queries in Mr. Plotter, so I investigated. This led me to make the following queries against BTrDB in a certain production cluster (details communicated to @immesys offline):

root@btrdb-0:/sam# ./btrdb-cmd-static localhost:4410
localhost:4410> windows bdff2d37-9f9d-553a-8f2d-e8240e48c622
-1152921504606846976,1.23079e-05,192.655,264.361,1635436680
Version: 0
localhost:4410> nearest bdff2d37-9f9d-553a-8f2d-e8240e48c622
1507507200000000000,158.534
Version: 129146
localhost:4410> windows 3c122dcf-c0ff-5da0-bf4b-31b4309ef446
Version: 10
localhost:4410> raw
Usage: raw UUID [start] [end] [version]
localhost:4410> raw 3c122dcf-c0ff-5da0-bf4b-31b4309ef446 -1152921504606846975 3458764513820540927 0
Version: 10
localhost:4410> nearest 3c122dcf-c0ff-5da0-bf4b-31b4309ef446
0,0
Version: 10
localhost:4410> nearest
Usage: nearest UUID [backward] [timestamp] [version]
localhost:4410> nearest 3c122dcf-c0ff-5da0-bf4b-31b4309ef446 false -100 0  
0,0
Version: 10
localhost:4410> nearest 3c122dcf-c0ff-5da0-bf4b-31b4309ef446 false 100 0
0,0
Version: 10

The stream bdff2d37-9f9d-553a-8f2d-e8240e48c622 is a stream with data, and things work as expected.

The stream 3c122dcf-c0ff-5da0-bf4b-31b4309ef446 exists but has no data. For this stream, the nearest queries always return the point (time = 0, value = 0) even if it's an invalid answer for the query at hand.

The same behavior actually happens if there is no valid "nearest" point (e.g., no points after that timestamp)

localhost:4410> nearest bdff2d37-9f9d-553a-8f2d-e8240e48c622 false 3458764513820540926
0,0
Version: 129148

This is bad because if I make a nearest query at a negative timestamp, I can't tell from the answer (0, 0) whether there was actually no data after that time, or whether the point is at (0, 0). I suggest that you revise the API by returning an error, rather than returning (0, 0). Alternatively, you could choose to return a point outside of the valid range to signal an error, or add a "no such point" flag to the returned protobuf.

samkumar commented 6 years ago

Seems that @immesys fixed this in commit 3c1697bb1e2e3c087f525926fee8787ba20282bf. Thanks!