plotly / dash-table

OBSOLETE: now part of https://github.com/plotly/dash
https://dash.plotly.com
MIT License
420 stars 72 forks source link

[BUG] Order of operators and split_filter_part in DataTable filtering example #688

Open dmitra79 opened 4 years ago

dmitra79 commented 4 years ago

I was having problems using DataTable back-end filtering even though I copied the example code from https://dash.plot.ly/datatable/callbacks For example, when on a string column I specified filter '= XFMR Outage', everything worked, but when I specified '= Line Outage', no filtering would happen. After adding some print statements, I realized that in split_filter_part these two cases ended up matching different operators:

Filter: {Event} = "XFMR Outage" PartFilter: Event; eq; XFMR Outage; Filter: {Event} = "Line Outage" PartFilter: Event; ne; Outage";

The problem is in the order of operators in the example code on the above-mentioned page. It is given as

operators = [['ge ', '>='], ['le ', '<='], ['lt ', '<'], ['gt ', '>'], ['ne ', '!='], ['eq ', '='], ['contains '], ['datestartswith ']]

So when working with strings, 'ne' in string 'Line' is matched as operator before '=' is detected. I'd suggest adding 'eq' alone into first position: operators = [['eq '], ['ge ', '>='], ['le ', '<='], ['lt ', '<'], ['gt ', '>'], ['ne ', '!='], ['eq ', '='], ['contains '], ['datestartswith ']] An even better solution could be to parse the argument to 'split_filter_part' by first extracting the column name and then checking the start of the next part for an operator.

alexcjohnson commented 4 years ago

This looks like https://github.com/plotly/dash-table/issues/563 which we solved back in October. Do you have the latest version of dash?

dmitra79 commented 4 years ago

I have python 3.7.5 and dash 1.8.0 - installed in couple days ago. The solution described in issue you linked seems to have been to add space after an operator, ie 'ne '. However, this wouldn't help when the search term is 'Line Output'.

alexcjohnson commented 4 years ago

Thanks for confirming the version @dmitra79 - I've moved this issue over to the dash-table repo, looks like a case we missed when dealing with #563