You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filtering got a major overhaul with #397 and #410. This issue is just to document and discuss some loose ends we may want to clean up.
eq and ne are not exact complements. For example 123, "123", and "123.0" are all both eq and ne to each other. I think we should extend number casting to at least ne and probably all the inequalities.
If you enter an invalid column type, no error is generated (even in debug mode) but there's no default operator. Either we should treat this as an any column, we should display an error, or both.
datetime columns should have their own comparisons. Currently a lot of things pass that probably shouldn't, like '2018-01-01 00:00' > '2018-01-01', not to mention effects of poorly-specified (yet still interpretable) dates like '18-1-1'. It may be as simple as, if both values are dates, converting them to milliseconds and comparing those, although we should consider some edge cases before settling on this: for example, if you say > '2017' we would convert that to the very first instant of 2017, so '2017-01-01 00:00:01' would pass. Is that what we want, or would we want only datetimes in the year 2018 and later to pass?
Option to filter on every keypress, ie without pressing enter, perhaps with a configurable debounce rate.
Filtering got a major overhaul with #397 and #410. This issue is just to document and discuss some loose ends we may want to clean up.
eqandneare not exact complements. For example123,"123", and"123.0"are all botheqandneto each other. I think we should extend number casting to at leastneand probably all the inequalities.anycolumn, we should display an error, or both.'2018-01-01 00:00' > '2018-01-01', not to mention effects of poorly-specified (yet still interpretable) dates like'18-1-1'. It may be as simple as, if both values are dates, converting them to milliseconds and comparing those, although we should consider some edge cases before settling on this: for example, if you say> '2017'we would convert that to the very first instant of 2017, so'2017-01-01 00:00:01'would pass. Is that what we want, or would we want only datetimes in the year 2018 and later to pass?