3 ms·
1) efficient implementation of data source for virtualized on top of relational (or otherwise not directly addressable) grid involves having some knowledge of h
by dfox 9y ago
1) efficient implementation of data source for virtualized on top of relational (or otherwise not directly addressable) grid involves having some knowledge of how the data looks in order to be able to get only the relevant part of data by using indices ant not by geting rows 1000-1100 by selecting first 1100 and then throwing first 1000 out (which is how LIMIT 100 OFFSET 1000 is implemented by essentially all SQL databases)
2) when presenting results of user supplied SQL in this way you have to rewrite it somehow, which means that database ends up running different query than what the user entered, which is counterintuitive behavior and there certainly are cases where it is not desirable at all.
- SigmundA 9y agoA virtualized grid does not mean the data request is virtualized all the way to the sql server. The main issue with displaying 100,000 rows in the browser is DOM overhead. A virtualized grid like Slickgrid which they are using, reuses dom elements as you scroll and in its simplest form is just backed by an in-memory JS object. Once you start exceeding what works well in memory you can move to a local temp file system, which it sounds like what they are doing. None of this has anything to do with the SQL server itself, it simply sends the entire result set to the client which deals with buffering and virtualizing it to the UI in whatever way necessary. This is how native SQL UI's tend to work, I have never seen one rewrite SQL to try and virtualize all the way to the DB. Obviously unless you do use the DB there will be limits, but 100,000 rows fits entirely in memory without issue: checkout this sample: http://mleibman.github.io/SlickGrid/examples/example-optimizing-dataview.html http://mleibman.github.io/SlickGrid/examples/example-optimiz...