Bug in api.cells when applying rows and modifier
Bug in api.cells when applying rows and modifier
guyclairbois
Posts: 9Questions: 1Answers: 0
When using api.cells to e.g. calculate a row total for a subset of the rows, there is some incorrect behaviour for the row with row id 0.
If the rowSelector contains row 0, the complete rowSelector input is ignored and only the modifier is considered. If the rowSelector contains only other rows than row 0, the rowSelector and modifier are combined to get to the final result (which is the expected behaviour).
I've composed a fiddle
In order to reproduce, load the page, then type 'air' in the Search box. The table will be filtered down to 1 record, with row Id 4.
The small table at the top contains some totals which are calculated in the footerCallback function.
- The type1ANDsearch column contains '33', which is the total Age of all searched rows. However, the type1Rows filter is not applied.
- The type2ANDsearch column contains '0', which is the combination of searched rows and type2 rows. This is the correct behaviour.
Now if we change row 0 to belong to type2 (by changing row 0's age to 30), the bug switches to the type2 totals.
And if we change row 0 to belong to no type at all (by changing row 0's age to e.g. 35), all totals are calculated correctly.
This leads me to believe that the bug has to do with the fact the row Id 0 is in the rowSelecter.
Did anybody run into this before, and/or developed a strategy to cope with it?
Many thanks,
Guy
Replies
Hi,
When I load the fiddle above and type "air" into the search input I get:
type1 rows contain row indexes 5 and 44.
type2 rows contain row indexes 10, 20, 53 and 0.
The row being displayed is row index 4.
I would say that both type1ANDsearch and type2ANDsearch should be 0 in this case. Would you agree?
Are you saying that you believe the issue is due to the
0in the type2 rows?Regards,
Allan
That's exactly what I mean, indeed.
And if I change row 0's data to match the type1 criteria, the bug moves to that place (as described).
And if I change row 0's data to match none of the 2 types, the bug disappears.
So this strongly points towards the 0 rowId.
Basically, if a 0 is part of the row id's, then the rowSelector behaves as if it is 'null'.
We need to be careful about how we use "id". This bug appears to be in the indexes, not the ids. There are no row ids here (which are DOM ids).
I agree - that is most certainly a bug which I will look at and post back here for.
Allan
Ah, you are right of course. I should have referred to 'index' instead of 'id'. Thanks for looking into this. Let's hope it's not too complicated to resolve..
Darn falsy expressions! I've just committed the fix and the nightly will rebuild with the fix in about 10 minutes.
This will ship in 1.10.13, which I don't expect to be too far away (a few weeks tops).
Thanks for spotting this and letting me know about it. Even more so for the test case, you've obviously put work into that!
Regards,
Allan
Nice, thanks! Greatly appreciate the work you put into this library!
When I open my fiddle now (using the nightly), it seems like the API.rows() was impacted as well (in a sense that it doesn't return any rows anymore...). Could this be due to the fix?
Yes - it will effect anything that uses the row selector (
rows(),row(),cells()andcell()).Allan
But now api.rows() (so without any parameter) is not returning any data at all, while I'd expect the complete set of rows to be returned.
Argh! Yup - that's the first thing I'll do when I get into the office...
Fixed properly here. I had forgotten that the selector will default to an empty string and to take that into account for the falsy expression.
Nightly will be up to date shortly again.
Thanks!
Allan
Yes looking fine now. Tnx again!