Difference between $.fn.DataTable.ext.search.push and $('#myDatatable).search.fixed

Matth

Hi,

I'm asking this difference because I have a little issue now.

If i do :

myTable.columns(0).search(myString).draw()

The old function ($.fn.DataTable.ext.search.push) is thrown on filtered data.
But the new one ($('#myDatatable).search.fixed) is thrown on every data.

I know that i can use $('#myDatatable').columns().search.fixed but it will be thrown on every column and i just need to trigger my script at the end of search.

I make a little test here => https://live.datatables.net/wenaretu/2/edit
Just click on search button top left to trigger the script.

I need that the new search.fixed work as the old way. How can I do that ?

Thanks

kthorngren

I think the key is this from the search.fixed() docs:

The primary difference from a standard search term is that a fixed search is not immediately replaced by the next search term applied. It is consistently applied to the table, until either replaced by name or is deleted.

Based on your test case and the docs this suggests that search.fixed() is applied before the search happens. The plugin is pushed to the end of the search array so it is applied last.

If the plugin meets your needs then you should continue to use it.

Kevin

Matth

The doc says we should stop using it, so I ask how I can replace it.

Legacy search

Support for DataTable.ext.search has been retained in DataTables 2 for backwards compatibility, but new projects should not use this API, and old projects should be ported to the new APIs.

If nothing is yet implemented, we can imagine a new parameter which would allow us to say whether the search applies before or after the other searches.

kthorngren

But the new one ($('#myDatatable).search.fixed) is thrown on every data.

Please explain the issue you are having with this?

This process is filtering out the rows you aren't interested in before the main Datatables search process. If search.fixed() returns 10 rows then the main search process will have 10 rows to search.

If its a performance issue maybe you can post your plugin so we can see if there are efficiencies that can be gained.

I'll let @allan comment on a new parameter.

Just my opinion if the plugin works better for you then I would stick with it since its been retained in 2. The link you referenced explains the downsides of using the plugin but if they don't affect you then stick with it. @allan can comment on this too

Kevin

allan

One other difference is that $.fn.DataTable.ext.search.push is applied to every DataTable on the page. Not just one specific table that the API instance points to, which is the case with search.fixed().

If nothing is yet implemented, we can imagine a new parameter which would allow us to say whether the search applies before or after the other searches.

The search is cumulative, so I don't see what different the order the search patterns are applied in makes? If a row is going to get filtered out, it will get filtered out regardless of if the search terms that removes it is first, second, third or nth in the sequence. The same applied with the legacy API.

I also don't understand what you mean by "is thrown on every data". A test case showing the issue would be useful.

Allan

kthorngren

is thrown on every data

The test case supplied shows the search.fixed() is called for each row. I think this is what is meant by "is thrown on every data"

Kevin

allan

Doh - sorry, I missed it.

The function needs to be called for every row since that is what is checking if the filter is passing or not. That was the case for the legacy API as well.

There was a change in v2 to have the filtering recalculate all rows rather than be progressive - before if you searched for "be" and removed other rows, those other rows couldn't be reinserted, but they can now, since you might do something like "be$".

So it is possible the function might be see more calls.

Allan

Matth

Hi,

Thanks for your response.

I understand the reason of this change.

I asked this because i try to make RowGroup collapsed like an arborescence (client needs...) and my script works well with the legacy search, but I have some difficulty with the new one.
I will find a way to do it

kthorngren

The RowGroup functions execute after searching is complete. Can you build a test case that replicates the issue so we can help debug?
https://datatables.net/manual/tech-notes/10#How-to-provide-a-test-case

Kevin