continuous queries are padding with 0 and nulls by default v0.11.1, order by DESC broken as well #6206
Comments
|
Hello, I have noticed a similar issue, I think it might be related. Steps to reproduce:
b gets padded with 0, a gets padded with null Seems inconsistent, in particular padding with default value 0 is annoying because 0 means that a value is present and equal to zero, whereas null means value is not present. |
|
Note I am running 0.11.1, only just noticed new version is now available. Will upgrade and check if bug is still present. |
|
I'm able to reproduce the bug. Thanks @ericremoreynolds. |
|
Confirm that it didn't happen with 0.10.3 |
|
@ianlutzeigen can you give me a way to reproduce the |
|
I think I managed to reproduce the |
Send nil values from the tsm1 cursor at the end of the cursor. After the cursor reached tsm1, the `nextAt()` call would always return the default value rather than a nil value. Descending also didn't work correctly because the seeking functionality for tsm1 iterators would always act like they were ascending instead of descending when choosing which value to select. This resulted in very strange output from the emitter since it couldn't figure out if it was ascending or descending. Fixes #6206.
Send nil values from the tsm1 cursor at the end of the cursor. After the cursor reached tsm1, the `nextAt()` call would always return the default value rather than a nil value. Descending also didn't work correctly because the seeking functionality for tsm1 iterators would always act like they were ascending instead of descending when choosing which value to select. This resulted in very strange output from the emitter since it couldn't figure out if it was ascending or descending. Fixes #6206.
Send nil values from the tsm1 cursor at the end of the cursor. After the cursor reached tsm1, the `nextAt()` call would always return the default value rather than a nil value. Descending also didn't work correctly because the seeking functionality for tsm1 iterators would always act like they were ascending instead of descending when choosing which value to select. This resulted in very strange output from the emitter since it couldn't figure out if it was ascending or descending. Fixes #6206.
Hi
I am running a bunch of CQs on "testdb" that downsample into a separate db called "testdb_downsampled"
What i am observing is that there are both "nulls" and "0s" for the sections of data where there is no data to be downsampled. Some CQs have zero some have none. I have not specified a fill type so it should be "null". These zeros are wrong....
note DESC is broken as well: what is with those time stamps ?
(note i have tested all this agains v.10.3 and that behaves as I would expect)
The text was updated successfully, but these errors were encountered: