Help me understand server-side "Draw" parameter

GregP

Description of problem: my particular implementation of server-side does not have a 1:1 request:response flow of data. I would like to make sure I am understanding and using "draw" properly, as documented for both client and server-side payloads: https://datatables.net/manual/server-side

My understanding of the typical flow of data for server side (with regard to "draw") is as follows:

1. Ajax is triggered by something like pagination or search or whatever
2. The parameter "draw" is collected from the instance. This parameter is an incrementing integer of how many draws have been requested/performed (not sure which). It is sent to the back end.
3. Back end echoes back an integer version (not string version) of the parameter, confirming that it is sending back a payload that matches the request. You wanted draw 3? Here's draw 3. If timing issues cause request 4 to return first, presumably when 3 returns it does not replace 4, which is newer.

But without a 1:1 request:response, the "draw" parameter actually means fairly little to me. I send isolated "update requests" that simply tell a broadcaster to start sending out different data. The back end can push out theoretically limitless additional data updates without an actual update request (the database itself has shifted, triggering a new update). Now, I can send the back end the current value of "draw" when a user does interact, but the back end won't be able to echo it in a way that is a guaranteed match to the update request.

What I can do is increment the back end's "draw" value every time it sends out a payload, period. Will this be sufficient for DataTables' internals to do anything useful with the parameter?

I don't seem able to just drop it from my custom "ajax" handler, because the render simply hangs/fails, so it needs to be present, either returned by back end or injected via front end.

allan

draw is used to make sure messages are handled in the correct sequence. As you say, if two requests go out quickly (3 and 4) and 4 comes back first, you wouldn't then want 3 to paint over the data for the newer request.

It is a simple counter internally, each draw request increments the counter by one. That is per client / per page load.

draw is optional. It should work without it. It's just that if you run into continuity issues, things will go wrong.

Allan

GregP

Thanks, Allan! One follow-up question-- does the incoming "draw" look for equivalence to the internally stored one, or is greater-than OK? We might not bother implementing a back-end counter in either case, but I'm curious.

In other words, when the replacement ajax function passes its "data" to the callback (containing an integer for draw), does it want there to be a match for the most recent request, or is a larger number sufficient?

allan

The check is done here. It checks against what it last sent, and if it doesn't match, then it throws it away.

Actually, looking at the code it does a < check, so you could have the server return draw: 9999999999 to sort of bypass that... I have thought about checking this mechanisim to get rid of the draw parameter through, so I would recommend hacking around things with it - it might change in future

Allan