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
{{ message }}
This repository was archived by the owner on Jun 4, 2024. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
Isn't that what we're doing now? Any text or any (untyped) column defaults to the contains operator, so you can just start typing, no eq, no quotes, and you'll get a substring match. You can use quotes and operators for more specific results, but you don't need to.
Filtering without pressing enter is something we haven't implemented yet. We've discussed it internally, but I don't think there's an issue for it yet. I've added it to the list above. Thanks for mentioning it!
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
andne
are not exact complements. For example123
,"123"
, and"123.0"
are all botheq
andne
to each other. I think we should extend number casting to at leastne
and probably all the inequalities.any
column, 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?The text was updated successfully, but these errors were encountered: