[svonmiller]

Yes I've double and triple checked all of those settings and all are correct. I've also checked exhaustively the RPC traces. It's all correct.

For testing, I removed manual RPC call and setfields, and simplified the listgrid, with autofetch:true. I set the servlet to return a 30K result set. I've set debugging logs on the result set, the results are below. And I've had someone looking over my shoulder to make sure I'm not missing something totally obvious. Is it possible we've got some server-side setting configured wrong? Like is there a server properties setting somewhere that would cause ISC to always send everything to the client?

16:46:07.727:XRP9:INFO:ResultSet:isc_ResultSet_51 (created by: searchResultsList):Received 27812 records from server
16:46:07.758:XRP9:DEBUG:ResultSet:isc_ResultSet_51 (created by: searchResultsList):full length set to: 27812
16:46:07.805:XRP9:DEBUG:ResultSet:isc_ResultSet_51 (created by: searchResultsList):integrating 27812 rows into cache at position 0
16:46:08.008:XRP9:INFO:ResultSet:isc_ResultSet_51 (created by: searchResultsList):cached 27812 rows, from 0 to 50 (27812 total rows, 27812 cached)
16:46:08.039:XRP9:INFO:ResultSet:isc_ResultSet_51 (created by: searchResultsList):Cache for entire DataSource complete
16:47:04.917:MUP1:INFO:ResultSet:isc_ResultSet_34 (created by: isc_PickListMenu_32):setCriteria: filter criteria unchanged
16:47:04.917:MUP1:DEBUG:ResultSet:isc_ResultSet_34 (created by: isc_PickListMenu_32):getRange(0, 1) satisfied from cache
16:47:05.354:MUP1:DEBUG:ResultSet:isc_ResultSet_51 (created by: searchResultsList):getRange(0, 8) satisfied from cache
16:47:14.995:RDQ9:DEBUG:ResultSet:isc_ResultSet_51 (created by: searchResultsList):getRange(27805, 27811) satisfied from cache
16:47:15.308:RDQ5:DEBUG:ResultSet:isc_ResultSet_51 (created by: searchResultsList):getRange(27803, 27811) satisfied from cache

[Isomorphic]

Once again: what you give to setData() is what is sent back. The server does not shorten the number of records.

You've got a DataSource of serverType:"generic", that means, none of the built-in connectors are active, you are fetching the data yourself. If there's too much data being returned, then you're passing too much data to setData().

[svonmiller]

Based on what I'd read in the documentation, I thought that isomorphic server component would cache the fetchresults, and the listgrid would get its subsets from the isomorophic server component. And in that regard, there was no need for a connector between isomorphic and the database. Is that not the case?

[Isomorphic]

No, it's not. Caching happens client-side, never server-side. The server-side is stateless for maximum scalability (especially with clusters).

[svonmiller]

So with the SmartClient_Explorer.html#fetchOperation example, and the Adaptive Filtering example, there is custom code on the backend that uses startRow and endRow to paginate the data returned? And is it done the standard way (first get total row count, then make secondary trips with start, end and limit size)?

[Isomorphic]

There is no custom code on the server in either case. The built-in SQL and Hibernate connectors support pagination out of the box. And again, the only caching that takes place is client-side caching based on the ResultSet object - that's why there are no requests to the server in various circumstances, which is the whole point of the Adaptive Filter sample.

See also the examples for DMI and Custom DataSources, which show how to write server-side code that takes startRow and endRow as passed by the client and forms a proper DSResponse to allow pagination.

[svonmiller]

Got it. So for the out-of-the-box pagination, we'd have a table that matches the datasource, then use the database config tool to setup the connector, and the listgrid goes back and forth that way. Otherwise with generic, we need to manually handle the back and forth. I'd already studied the custom datasources examples a number of times, but knew there was a way to automatically paginate that didn't require the custom approach. I just didn't fully understand that it involved connectors and thought there was some sort of internal caching going on.

[Isomorphic]

Right, a particular server-side DataSource can either support pagination or not, and the built-in ones (SQL, JPA/Hibernate) support it out of the box.

Also, there's no requirement that your DataSource matches up to a particular table, even when using SQL. It can be a complex join query, or some operations might just run custom Java logic to do several SQL queries, or modify results, etc.