Column type inferred from data-order used for searching?

michaelkubovic

Let's have a rendered table in DOM, with a single column of strings. Each of these string cells has a data-order attribute with a numerical representation of that string. By exploring table.settings()[0].aoColumns[i].sType I've noticed that column type is "num".

The problem arises, when you search in a column using column().search() and have a search extension bound to $.fn.DataTable.ext.type.search.string. It doesn't get called because the type is no longer a string, but rather a num.

I would expect that adding a custom value for ordering/sorting a table does not affect a value for searching/filtering in any way.

The docs state that you can customize any of these values independently, but it doesn't state that if you customize just one of them, it changes the type for the others.

By default DataTables will use the same data for all four operations, but this can easily be modified using the data and columns.render initialisation option, or HTML 5 data-* attributes.

colin

Hi @michaelkubovic ,

That sounds like it may be an issue, but there's a lot going on there. Could you link to a running test case showing the issue so we can offer some help, please. Information on how to create a test case (if you aren't able to link to the page you are working on) is available here.

Cheers,

Colin

michaelkubovic

Here, have a look http://live.datatables.net/qejafuju/1/edit

The office filter does not pick up search string extension because of applied data-order attributes, while country filter works as expected.

Type "Sco" to country filter and see "Scótland" appear in results. Now try entering "Edi" to office filter, but "Edínburgh" does not appear in results. You see?

allan

Yes - what is happening here is that the column type is automatically being detected as a number, since the type detection will run on the data-order if a data-type isn't given.

A quick workaround in this case is to have the number search formatter match the string search formatter:

$.fn.DataTable.ext.type.search.num = $.fn.DataTable.ext.type.search.string;

http://live.datatables.net/qejafuju/2/edit

Allan

michaelkubovic

Thank you for your explanation, I believe it would be a nice addition to the docs.
It wasn't clear to me, that secondary value, while it's sole purpose is sorting, changes a type for the rest of functionality, it still smells like a bug, doesn't it?

Additionally, if you have a cell with a string content, have a data-filter with a string content and apply data-order with integer value, you cannot even search the cell as a string. Even though data-filter is applied, which has higher precedence in the searching/filtering context than data-order, the column type is the one from data-order.

At a bare minimum, a secondary, supporting values supplied with data- attributes, aimed specificaly for some use-case (order/filter) should not change a global column type.

Ideally, each if these values would have type guessed independently.

I've tried your suggested quick-fix, however data-type didn't help, have a look.
http://live.datatables.net/qejafuju/4/

allan

changes a type for the rest of functionality, it still smells like a bug, doesn't it?

Sort of . The main point of the type detection is actually for the sorting. It can be used for filtering control as well, but for by far the majority of cases the type detection is used for the sorting only. The bug is probably that I've not communicated this very well.

Ideally, each if these values would have type guessed independently.

Agreed! And I've been moving towards that, but it isn't fully implement yet I'm afraid.

<td data-type="string" data-order="0">Edínburgh</td>

Yes, that isn't currently going to work since it is saying that the order should be done as a string. That absolutely is a weakness in DataTables that is going to be corrected for v2.

Allan