MLDBFB-441 distinct_timestamps bad ts value kept test case #290
Conversation
|
On hold. I could fix test_MLDB_1509 instead. |
testing/MLDB-724-time-arithmetic.py
Outdated
| "columns": [ | ||
| ["distinct_timestamps(colA).0", | ||
| {"ts":"1970-01-01T00:00:00Z"}, | ||
| "1970-01-01T00:00:00Z"], # <--- MLDB returns the 5th second |
There was a problem hiding this comment.
This is expected. We return the list of known distinct timestamps at the latest timestamp.
There was a problem hiding this comment.
Yes, this is expected. The result of the distinct_timestamps() function is an embedding (an array) of timestamps (those are the values) and the timestamps of the timestamps are all set to the latest timestamp.
timestamp timestamp timestamp
| @@ -604,21 +613,21 @@ def test_MLDB_1509(self): | |||
| { | |||
| "ts": "2015-01-01T00:00:00Z" | |||
| }, | |||
| "2015-01-03T00:00:00Z" | |||
| "2015-01-01T00:00:00Z" | |||
There was a problem hiding this comment.
Otherwise we lose the power of the "WHEN" operator.
There was a problem hiding this comment.
can you elaborate?
There was a problem hiding this comment.
Edit: We lose the some of the power of the "WHEN" operator in the particular use case that interrests me.
With the current implementation, that cell/value is kept with a WHEN value_timestamp() > to_timestamp('2015-01-02T00:00:00Z'). I want it to be discarded.
I'm investigating alternatives. I can probably push the distinct_timestamps usage later in the pipeline at the cost of performance.
|
@nicolaskruchten Good to go now. |
No description provided.