Seebs 7cf2c5b07e handle integers as comparisons for decimal fields ... It's reasonable to allow "where x > 13" on decimal fields. Handle at least int64 and float64. Once this is up, we find that aggregates can return non-values, such as nil, in some cases; for instance, `percentile(x) where x > 13` can yield a nil if x is never greater than 13, rather than making up a value from zero data points. So we accept nil as a valid result type in PQL aggregates. As a result of this, change two tests which were unintentionally testing for an arcane edge case bug in which (1) we can't render a condition to PQL, such as because you specified an integer for a decimal field, and (2) the filter is using an aliased name, in which we would end up failing to generate a PQL filter, but *also* losing the SQL-layer filter, and produce wrong results as though there were no filter. We also alter the tests to use `o.price > 9`, because this lets us generate three user names, but only two distinct user names, so the test using DISTINCT returns a different value than the test not using DISTINCT, which helps us verify that it's actually working and not just lucky. As part of fixing that, there was an intermediate state where we rejected as an error any case where generating the PQL filter failed. This broke 21 more test cases, but in all of those cases, the SQL filter was actually working. ... But in two of them, we SHOULD have been able to generate PQL, because they were testing bools for null, which works fine. We just had a list of field types we allowed null tests against and omitted bool because I forgot that bool isn't always just treated as a kind of mutex.		2023-04-07 15:52:26 -05:00
..
defs	handle integers as comparisons for decimal fields	2023-04-07 15:52:26 -05:00
helpers.go	Fb 2048 (#2363)	2023-04-03 12:04:41 -05:00