E
egarcia
Guest
Hello, I also found that for some dataset sizes, using local paging, filtering, and sorting is fine. Others would benefit from a server side operations. Other may require custom implementation of query (READ) and count. It would be interesting to see where the 0.5 delay comes from. Whether it is the network or the query/count resolution. Your suggestion of the delay being 5 seconds with a 10x dataset, would imply that it is caused by the query/count resolution. In some cases, the sample count implementation performs fast enough (with indexes). Even though it would be possible to save the filter and only call count if the filter has changed, this might not be sufficient if records have been added to the server and the client does not perform the next page request because it is logically already on the last page. It would all depend on whether you would want count to be able to change based on the records on the server or use count to only mean the number of records found on the first count request. Also, changes to fields involved in the filter by the client may result in a different count. Something to consider is that you can change the implementation of count (and read/query as well) in the Business Entity to improve its performance. If you are working with a large number of records, you could cache in a database table the filter and the count. The next request from any user with the same filter would only need to get the value for the count rather that calculating it. When records are created/updated/removed, you could update the count on the table, asynchronously and independently of the request from the client. Another alternative, could be to use the "Session Context" functionality. We added a mechanism where you can send properties from the client to the server and also receive them from the server. (Implemented via HTTP headers which can be used with WebSpeed.) For example, you could create an ID for the filter, either on the client or the server, pass it using the session context and use the ID as the key to get the count of records. You could also override the count method on the JSDO and use a value for count return with the READ request. In this way saving a network request. Please let me know if you would like more detail on this. I hope this helps.
Continue reading...
Continue reading...