Server-side processing
There are times when reading data from the DOM is simply too slow or unwieldy, particularly when dealing with many thousands or millions of data rows. To address this DataTables' server-side processing feature provides a method to let all the "heavy lifting" be done by a database engine on the server-side (they are after all highly optimised for exactly this use case!), and then have that information drawn in the user's web-browser. Consequently, you can display tables consisting of millions of rows with ease.
When using server-side processing, DataTables will make an Ajax request to the server for each draw of the information on the page (i.e. when paging, ordering, searching, etc.). DataTables will send a number of variables to the server to allow it to perform the required processing and then return the data in the format required by DataTables.
Server-side processing is enabled by use of the serverSide
option, and configured using ajax
. See below for further information on configuration options.
Sent parameters
When making a request to the server using server-side processing, DataTables will send the following data in order to let the server know what data is required:
Parameter name | Type | Description |
---|---|---|
draw |
integer |
Draw counter. This is used by DataTables to ensure that the Ajax returns from server-side processing requests are drawn in sequence by DataTables (Ajax requests are asynchronous and thus can return out of sequence). This is used as part of the draw return parameter (see below). |
start |
integer |
Paging first record indicator. This is the start point in the current data set (0 index based - i.e. 0 is the first record). |
length |
integer |
Number of records that the table can display in the current draw. It is expected that the number of records returned will be equal to this number, unless the server has fewer records to return. Note that this can be -1 to indicate that all records should be returned (although that negates any benefits of server-side processing!) |
search[value] |
string |
Global search value. To be applied to all columns which have searchable as true . |
search[regex] |
boolean |
true if the global filter should be treated as a regular expression for advanced searching, false otherwise. Note that normally server-side processing scripts will not perform regular expression searching for performance reasons on large data sets, but it is technically possible and at the discretion of your script. |
order[i][column] |
integer |
Column to which ordering should be applied. This is an index reference to the columns array of information that is also submitted to the server. |
order[i][dir] |
string |
Ordering direction for this column. It will be asc or desc to indicate ascending ordering or descending ordering, respectively. |
order[i][name] |
string |
Name of the ordering column, as defined by columns.name . |
columns[i][data] |
string |
Column's data source, as defined by columns.data . |
columns[i][name] |
string |
Column's name, as defined by columns.name . |
columns[i][searchable] |
boolean |
Flag to indicate if this column is searchable (true ) or not (false ). This is controlled by columns.searchable . |
columns[i][orderable] |
boolean |
Flag to indicate if this column is orderable (true ) or not (false ). This is controlled by columns.orderable . |
columns[i][search][value] |
string |
Search value to apply to this specific column. |
columns[i][search][regex] |
boolean |
Flag to indicate if the search term for this column should be treated as regular expression (true ) or not (false ). As with global search, normally server-side processing scripts will not perform regular expression searching for performance reasons on large data sets, but it is technically possible and at the discretion of your script. |
The order[i]
and columns[i]
parameters that are sent to the server are arrays of information:
order[i]
- is an array defining how many columns are being ordered upon - i.e. if the array length is 1, then a single column sort is being performed, otherwise a multi-column sort is being performed.columns[i]
- an array defining all columns in the table.
In both cases, i
is an integer which will change to indicate the array value. In most modern server-side scripting environments this data will automatically be available to you as an array.
Returned data
Once DataTables has made a request for data, with the above parameters sent to the server, it expects JSON data to be returned to it, with the following parameters set:
Parameter name | Type | Description |
---|---|---|
draw |
integer |
The draw counter that this object is a response to - from the draw parameter sent as part of the data request. Note that it is strongly recommended for security reasons that you cast this parameter to an integer, rather than simply echoing back to the client what it sent in the draw parameter, in order to prevent Cross Site Scripting (XSS) attacks. |
recordsTotal |
integer |
Total records, before filtering (i.e. the total number of records in the database) |
recordsFiltered |
integer |
Total records, after filtering (i.e. the total number of records after filtering has been applied - not just the number of records being returned for this page of data). |
data |
array |
The data to be displayed in the table. This is an array of data source objects, one for each row, which will be used by DataTables. Note that this parameter's name can be changed using the ajax option's dataSrc property. |
error |
string |
Optional: If an error occurs during the running of the server-side processing script, you can inform the user of this error by passing back the error message to be displayed using this parameter. Do not include if there is no error. |
In addition to the above parameters which control the overall table, DataTables can use the following optional parameters on each individual row's data source object to perform automatic actions for you:
Parameter name | Type | Description |
---|---|---|
DT_RowId |
string |
Set the ID property of the tr node to this value |
DT_RowClass |
string |
Add this class to the tr node |
DT_RowData |
object |
Add the data contained in the object to the row using the jQuery data() method to set the data, which can also then be used for later retrieval (for example on a click event). |
DT_RowAttr |
object |
Add the data contained in the object to the row tr node as attributes. The object keys are used as the attribute keys and the values as the corresponding attribute values. This is performed using using the jQuery param() method. Please note that this option requires DataTables 1.10.5 or newer. |
An example of how a return looks using these options is shown below in the "Example data" section below.
Configuration
Server-side processing in DataTables is enabled through use of the serverSide
option. Simply set it to true
and DataTables will operate in server-side processing mode. You will also want to use the ajax
option to specify the URL where DataTables should get its Ajax data from. As such, the simplest server-side processing initialisation is:
$('#example').DataTable( {
serverSide: true,
ajax: '/data-source'
} );
Configuration of how DataTables makes the Ajax request is configured through the ajax
option. In the above example we used it as a string, which instructs DataTables to use its default settings for making the Ajax request. However, you can customise these settings by passing ajax
in as an object. As an object, ajax
maps directly onto the jQuery ajax
configuration object, so any options you can use in a jQuery request, you can also use with DataTables! For example, to make a POST request:
$('#example').DataTable( {
serverSide: true,
ajax: {
url: '/data-source',
type: 'POST'
}
} );
For further information about the Ajax options available in DataTables, please refer to the ajax
documentation.
Legacy
Older versions of DataTables (1.9-) used a different set of parameters to send and receive from the server. As such scripts which are written for DataTables 1.10+ will not be able to function with DataTables 1.9-. However, DataTables 1.10 does have a compatibility mode for scripts written for 1.9-. This compatibility mode is triggered by use of the old sAjaxSource
parameter (rather than the new ajax
parameter) or by setting $.fn.dataTable.ext.legacy.ajax = true;
.
For documentation on the 1.9- method of performing server-side processing, please refer to the legacy documentation.
Example data
Example of server-side processing return using arrays as the data source for the table (full example):
{
"draw": 1,
"recordsTotal": 57,
"recordsFiltered": 57,
"data": [
[
"Angelica",
"Ramos",
"System Architect",
"London",
"9th Oct 09",
"$2,875"
],
[
"Ashton",
"Cox",
"Technical Author",
"San Francisco",
"12th Jan 09",
"$4,800"
],
...
]
}
Example of server-side processing return using objects, with DT_RowId
and DT_RowData
also included, as the data source for the table (full example):
{
"draw": 1,
"recordsTotal": 57,
"recordsFiltered": 57,
"data": [
{
"DT_RowId": "row_3",
"DT_RowData": {
"pkey": 3
},
"first_name": "Angelica",
"last_name": "Ramos",
"position": "System Architect",
"office": "London",
"start_date": "9th Oct 09",
"salary": "$2,875"
},
{
"DT_RowId": "row_17",
"DT_RowData": {
"pkey": 17
},
"first_name": "Ashton",
"last_name": "Cox",
"position": "Technical Author",
"office": "San Francisco",
"start_date": "12th Jan 09",
"salary": "$4,800"
},
...
]
}
A full set of examples, exploring the options available for server-side processing is available in the examples section of this site.