Skip to content

Accept iDisplayStart as part of _fnAjaxUpdateDraw's json parameter #236

wants to merge 1 commit into from

3 participants


I believe DataTables should accept iDisplayStart as a parameter to _fnAjaxUpdateDraw so that developers in the case the DT becomes out of sync with the backend.

Take the following scenario:

DataTables 1.9.4 with Scroller 1.1.0.
1) User A scrolls down to the bottom of the table where iDisplayStart is now, say, 120.
2) User B decides to delete every row except for a couple. The backend is now empty except for 2 items.

3) User A reloads the page. At this point, user A sees the last couple items render at position 120. Interestingly, DT will correct itself less than a second later. This makes the items effectively "jump" from the bottom to the top of the table.

This is essentially the problem we are hitting in our application. We believe this happens because DataTables and the backend are out of sync in terms of the start index. At step 3, DT requests items from 120, yet the backend returns with 2 items that start at index 0.

Our solution was to simply allow our API to return the correct start index, and let DT know about it by passing the start index as part of the json parameter passed to fnServerData's callback (along with iTotalRecords, iTotalDisplayRecords, etc). I am not sure how DT can otherwise figure out the correct start index.


(I know we had a thread going on via email, but I figured I'd just create the pull-request so we can track it here. Hope you didn't mind =) )


Thanks very much for the pull request! Sorry for the delay in getting back to you about this and by e-mail - busy times at the moment :-).

This is a very neat little fix - I like it. However, I'm wondering if it is enough for situations such as this. For example, it would be perfectly possible to have one user delete all records from one browser, while another user is browsing the table. Even worse would be for that first user to then add new items.

The ultimate solution would be a web socket with realtime information for the table, but I'm wondering if a hash of the database state might be a good interim solution. Not even sure if databases would be able to provide that kind of information efficiently, but a change in hash could mean a reset for the table. What do you think?


I don't think even websockets will do justice. It would just mean the table would update without any user prompt, whereas with the current implementation, users will need to scroll before they notice that all of the data is gone.

There needs to be logic outside of the table that handles these conflicts. For example, if the client detects data has changed on the backend, a notification can show up above the table - "Table has been updated, click here to refresh". Twitter does this with tweets.

I think its ultimately up to the developer to decide how to handle these conflicts. For our application, we were OK with the current implementation because the chance of a user deleting everything is very, very slim. We just happened to notice this issue because of testing.


This edit is better than current working process. Maybe just need a test as seen here :

if (json.iDisplayStart !== undefined) { ... }

I use datatable with a filter form and bStateSave enabled. If I browse 6th page, then filters, sending back only 2 results pages, I'm still on 6th page with no result on screen. Getting control of iDisplayStart is enough to provide consistent information.


If I browse 6th page, then filters, sending back only 2 results pages, I'm still on 6th page with no result on screen

This is wrong. If you filter the iDisplayStart parameter should be set back to 0 and the first page shown.


I meant a POST filter outside of datatable.


Can you link me to the page please so I can take a look and see what is going wrong. Also, it would be good if you could open a separate issue or ideally a forum thread about this.


I have no public page for this...

My request is exactly what is mentionned as commit's message for khirakawa@5396f09

I have a form that handles data provided in a datatable. POST params are stored in session so that datatable always deals with filters set by form, but it does not itself "know" filters data.

I can open a new Pull Request with nearly the same commit if you prefer to handle this apart.


No - don't bother opening an identical pull request. I just wanted to understand the problem you are having better.

Anyway, good to hear that the change from khirakawa helps to resolve your problem.


You're not gonna merge this pull request ?


Not just yet. I will review it properly and include it if appropriate in future. I'm currently tied up working on the documentation for DataTables 1.10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.