So in order to do that i need to remove pager: value in grid declaration and i need to set maximum rows number to rowNum: 100000000,, according with that post How to show all rows in the jqGrid?
But what about json which i need to return from server,
var jsonData = new
{
total = totalPages,
page = page,
records = totalRecords,
rows = ...
}
Which values better to assign to page and totalRecords in that case?
Should i better pass them as zeroes or it is doesn't mater at all in such case?
UPDATE:
I think i would set records to total number rows that will go to jason, and page and total i will set to 1
What do you think? Anymore i can do to correctly turn off jqGrid paging?
It's correct to place page and total to 1 and records to the total number rows. The setting rowNum: 100000000 seems to too large. If you will really post back from the server 100000000 rows of data the user will probably never see the grid. It seems enough to set rowNum to 10000.
If you don't use tree grid you can use local paging of data. In the case you need set just loadonce:true. In the case the server should post all the data to the client and just ignore the input rows parameter. Look at the demo which uses local data paging of 5000 rows of data here and compare the results with the same demo without local data paging here. The difference in the performance will show why I recommend you to use local data paging instead of scrolling the same data in the browser.
Related
I have a Golang server that fetches all the rows from a database table.
SELECT * FROM people;
The fetched data is 'marshaled' into JSON:
json.NewEncoder(w).Encode(people)
JavaScript can fetch the rows through its Fetch API.
Now let's say the database table has 10,000 rows but I only want to display as many rows as they fit on the screen.
As I scroll the page I'd like more rows to be fetched dynamically from the database.
Does the client need to send data to the server telling the server to fetch the JSON again with more data?
I would be grateful for any suggestion. Thank you!
Assuming what you're looking for is pagination, then the answer is quite simple, but it requires changes both on the client and the server side:
Getting the data: You'll want the client-side to tell the server how big the batches of data should be (typically 10, 20, 30, 40, or 50 results per call, with a default value of 10).
The second parameter you'll want from the client is to indicate how many results the client has already loaded on their end.
With these two values, you'll be able to enrich the query to include a limit and offset value. The default offset being 0, and default limit being 10.
That means the first query will look something like:
SELECT * FROM people LIMIT 10 OFFSET 0;
This is often shortened to LIMIT 10; or LIMIT 0, 10;.
Now if the client scrolls down, to load the next 10 records, you'll want them to perform an AJAX call providing you the batch size, and the offset value (how many records are already displayed), then just plug in these values, and you'll get:
SELECT * FROM people LIMIT 10 OFFSET 10;
This query tells the DB to skip the first 10 results, and return the next 10.
If you're using actual pages, another common way to handle this is to have the client provide the page size value, and the page number. For example: I want to see 20 people per page, and I want to jump directly from page 1 to page 5, the parameters passed to the server would be something like: page_size=20&page=5
That means that I need a query that skips the first 80 records (20 times 4 pages), a trivial computation:
offset := pageNr * pageSize - pageSize // or (pageNr -1 ) * pageSize
For the query to be:
SELECT * FROM people LIMIT 20 OFFSET 80;
Some general tips:
Avoid SELECT * as much as possible, always be explicit about the fields you select. Adding fields to a table is common, and using select * can result in exposing data you don't want people to see, or your code messing up because it can't handle new fields
Specify the order for your data. Have a created_at field in your table, and sort by that value, or sort by name or whatever. If you don't sort the results in a particular way, how can you guarantee that the first 10 results will always be the same? If you can't guarantee that, why wouldn't it be possible that you're going to skip some records, and display others twice?
Create a People type server-side that represents the records in the DB if you haven't already
It's been quite a number of years since I've done any front-end work, but to know when you need to load more records, you'll want to write some JS that handles the scroll event. There's a number of plugins out there already, and my JS is most likely outdated, but here's an attempt (untested, and to be treated as pseudo-code):
document.querySelector('#person_container').addEventListener('scroll', (function(ls) {
var last = ls[ls.length-1] // last person already loaded
let batchSize = ls.length // IIRC, let is used instead of var now
// returning the actual handler
return function(e) {
// scroll reached bottom of the page
if ((window.innerHeight + window.scrollY) >= document.body.offsetHeight) {
// make AJAX call with batchSize + offset, append new elements after last element
}
};
}(document.querySelectorAll('.person_item')))
i'm implementing a web page that shows certain rows fetched from a database.
At loading, i make an AJAX request to fetch the rows in a certain range of time(the initial call will take today's rows), and save them in a global variable(e.g "rows").
I have two text field to set the starting and the ending point of my research, and every time i change the value of those text-fields, i make another call to the db to get the new data and update global "rows" variable.
My question is: if i have different text-field filters and sort options that apply filters and sort to the fetched rows, should i make another request to the db(with the selected filters/sort) and let the db handles the filter/sort, or should i apply the filters/sort directly the global "rows" variable?
Of course i think the db filtering and sorting would be more efficient, but the number of rows shouldn't be more than 100, max 200 rows, and i was wondering if it would be worth it to make another AJAX request just for filter the result.
Thank you very much in advance.
have you try with datatables server side??
https://datatables.net/examples/data_sources/server_side.html
I think is a good options for you and very easy to implement
In kendo-grid there is option to sort the column data by clicking on column header, but sort is applied on only the current page data.
Suppose I fetched 100 records from database, and choose to keep pagination of 10 records at a time on GUI,so that at a time we can see 10 records on the webpage.
Now, my requirement is to apply sort not on only 10 records, rather all fetched record.
Any suggestion is welcome.
Server sorting is the only way to go. Please check this:
http://docs.telerik.com/kendo-ui/api/javascript/data/datasource#configuration-serverSorting
I have 100,000 records right now (will grow in future). I have JSON api call (remote URL, however, within same server) to get those records. If I use KendoUI with paging turned on (say 50 per page), will KendoUI datasource going to fetch all those records and bring them into client and apply paging? Or is it something I need to pass to the server (page size) to be able to only get only needed data for display? If I need to pass, do I have to write custom data source query methods?
Same question goes for using filter input boxes in toolbar within KendoUI.
There are two (efficient) ways of loading that amount of data:
Setting serverPaging to true in the DataSourcedefinition.
Using serverPaging plyst (as #bobosov534 and #gitsitgo suggests) virtual scrolling.
In the both you receive in the server tow parameters: top indicating the number of records to retrieve (what you have defined as pageSize) and skip for the number of records to ignore (no skip means the first top records).
The difference is that int the first you see a pagination bar in the bottom of the grid and in the second you see additional records as you scroll down.
In DataSource.serverPaging you find detailed information on the fields sent to the server for managing pagination.
I am using ASP/VB Script in my project but, i don't have much idea of Pagination in Classic ASP. I have designed a datagrid format using tables and looping. That table is filled by accessing database. As we have a huge amount of data to display, we need pagination.
Thanks in advance
The pagination problem is not inherently to ASP classic or VBScript. You need first to define which strategy to follow:
In the client:
Ajax style pagination (You can use a jQuery plugin like SlickGrid)
Linked pagination: Your page have links to page 1, page 2, etc.
Infite scrolling: This is a modern way to do pagination, with more results added to the page via ajax
In the server
Full DB results retrieve and return only the page asked. This is sometimes necessary.
Full DB retrieve but caching the result so subsequent page request come from the cache, not the DB
Ask the DB only the page asked (Different techniques depending on the DB engine)
There is a issue you need to be aware of... the built-in ASP record set will allow pagiing, however is not very efficient. The entire result set gets returned to the browser and then it locates the appropriate page and displays that data.
Think of it like this... your result set is a 4 shelf book case. When you ask for page one all 4 shelves of books get returned. The the display code says "Okay now only show page 1". If you then ask for page two... All four shelves of books gets returned and then the display code says "Okay give me page 4".
So, you should look for a paging solution that takes place on the server, inside the database. This way if you ask for page 15 of a 50 page result, the database will only return one shelf of books.
This google query should put you on the right track.
Edit: How SQL Paging Works
You must us a stored procedure
One of the input parameters is the page to view
The stored procedure filters the results on the server
Here is the basic concept of what happens inside the proc:
Step 1:
Create a temp table that stores the entire result set. My preference is to store only two values in this temp table. An identity seed value called RowId and the primary key of the result data. (I'm one of those people that believes in non-sensical identity seed keys)
Step 2:
Insert all the PKey values from the select statement into the temp table
Step 3:
Determine the StartRowId and EndRowId based on the input page parameter.
Step 4:
Select from the temp table using an inner join to the datatable on the PKey. In the where clause limit the result so the RowId (of the temp table) is between StartRowId and EndRowId. Make sure to Order By the RowId.
Set page size
recordset.PageSize = 100 ' number of records per page
Set the current page
recordset.AbsolutePage = nPage ' nPage being the page you want to jump to.
Other useful bits:
recordset.RecordCount ' number of records returned
recordset.PageCount ' number of pages based on PageSize and RecordCount
That's the basic info. You'll still need to loop through the appropriate number of records, and check the page number as it is passed back to the page.