Skip to content

Your getting the full recordset every time? #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ASKemp opened this issue Jun 24, 2019 · 3 comments
Closed

Your getting the full recordset every time? #2

ASKemp opened this issue Jun 24, 2019 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@ASKemp
Copy link

ASKemp commented Jun 24, 2019

Not sure what the point of this demo is since your controller is getting the full 1000 records each time and you are then just cutting the page number out of the pack to return back to the view.

Surely you should be formulating the resultant query to only be selecting the page number of records each time otherwise there is not much point.

Additionally, your controller is counting all the records a second time each call rather than just getting the count from the query before it is filtered.

@DavidSuescunPelegay
Copy link
Owner

DavidSuescunPelegay commented Jun 24, 2019

Yes, that's true, the way in which this project was created, was just a basic way to "render" the datatable in a MVC controller in a server-side way.

If we use the common way (render the 1000 rows in client-side), the load would last more than 5 seconds, because we print the raw HTML table and then the framework has to redraw all the table, and paginate it, if we send only 10 rows to Razor, the framework would rendered it pretty fast.

However, I'm working in a new version of the project with an improved LINQ-query, this new version would only load the first 10 registers with all the current options (filtering by word, order by criteria and pagination), using the List interfaces instead of a memory List object.

Stay tuned and I wish you enjoy the new version!

@DavidSuescunPelegay DavidSuescunPelegay added the enhancement New feature or request label Jun 24, 2019
@DavidSuescunPelegay DavidSuescunPelegay self-assigned this Jun 24, 2019
@xnetdude
Copy link

xnetdude commented Apr 19, 2020

@DavidSuescunPelegay - nice work, thank you!

You could build the query using IQuerable and latterly append the skip/take eg.

var bigDataset = await mydatatable.Skip(dtParameters.Start).Take(dtParameters.Length).ToListAsync();

Only when you either return this from the "code behind" or cast into a list will the query actually be sent to the underlying database which will only then return the subset of data because the LINQ created query includes the "offset" and "fetch" verbs.

This works well for us when using datatables.net with tens of thousands of rows (the row count is, ofc, totally academic as we only return x at a time).

@DavidSuescunPelegay
Copy link
Owner

Hi @ASKemp and @xnetdude thanks for your advices and patience for leaving me an issue.

Following your ideas I've redesign the TestRegisterController.cs, adding a dynamic Where clause and a dynamic OrderBy clause with an IQueryable, this helps reduce a lot the processing time.

I've also made another fews improvements to the Razor views, the JS and I've updated some outdated NuGet packages.

In addition to that, I've created several branches, just in case you want to check old code, here are the branches https://github.com/DavidSuescunPelegay/jQuery-datatable-server-side-net-core#branches

In the few days I'll push more branches, using the new versions .NET Core 3.0 and .NET Core 3.1.

I'll stay tuned for any advice you want to give me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants