Skip to content

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

Open
khirakawa wants to merge 1 commit into
DataTables:masterfrom
khirakawa:master
Open

Accept iDisplayStart as part of _fnAjaxUpdateDraw's json parameter#236
khirakawa wants to merge 1 commit into
DataTables:masterfrom
khirakawa:master

Conversation

@khirakawa

@khirakawa khirakawa commented Oct 29, 2013

Copy link
Copy Markdown

I believe DataTables should accept iDisplayStart as a parameter to _fnAjaxUpdateDraw 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.

Thanks!

(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 =) )

@DataTables

Copy link
Copy Markdown
Collaborator

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?

@khirakawa

Copy link
Copy Markdown
Author

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.
image

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.

@alterphp

Copy link
Copy Markdown

This edit is better than current working process. Maybe just need a test as seen here : http://www.datatables.net/forums/discussion/comment/4528#Comment_4528

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.

@DataTables

Copy link
Copy Markdown
Collaborator

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.

@alterphp

Copy link
Copy Markdown

I meant a POST filter outside of datatable.

@DataTables

Copy link
Copy Markdown
Collaborator

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.

@alterphp

Copy link
Copy Markdown

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.

@DataTables

Copy link
Copy Markdown
Collaborator

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.

@alterphp

Copy link
Copy Markdown

You're not gonna merge this pull request ?

@DataTables

Copy link
Copy Markdown
Collaborator

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants