It looks like, the JSDO invokes the "count" method on the AppServer in every case. Even when the prior call to retrieve data returns less rows than requested.
Isn't it fair to assume, that when the JSDO requests 10 rows and the server returns 0..9 rows, that this is the total number of rows? Or are the actual call to fetch data and the count request executed asynchronously?
Is that something I could add in our JavaScript code? Or would that require a change in the source of the JSDO?
Speaking of possible enhancement requests to the JSDO - would PSC expect us to file an issue on Github for that?
Hello Mike,
Thank you for the suggestions.
The calls are done in sequence, first read then count.
Returning 0-9 rows when requesting 10 rows means that you are at the last page. However, the number of records may not necessarily be 0-9 since there could be more pages. Each page request could be different from the previous one, for example you could specify a filter. This means that we cannot take advantage (in a simple way) of knowing the previous count.
We could optimize the case for when the first page has been requested and the number of records returned is less than the page size. Is this the case that you are concerned about?
We could also optimize the case for when a filter has not been specified and the last page is returned.
You could add a local count that returns a Promise to override the invoke, however, this change is something that would be better implemented in the JSDO code, specifically in the code that interacts with the Kendo UI DataSource (you can search for countFnName to see where it is used).
In the future we may return the count with a response for read.
Since the JSDO is open source, you could use GitHub or the regular channels for submitting an enhancement request.
Thank you and regards.
Hello Mike,
Thank you for the suggestions.
The calls are done in sequence, first read then count.
Returning 0-9 rows when requesting 10 rows means that you are at the last page. However, the number of records may not necessarily be 0-9 since there could be more pages. Each page request could be different from the previous one, for example you could specify a filter. This means that we cannot take advantage (in a simple way) of knowing the previous count.
We could optimize the case for when the first page has been requested and the number of records returned is less than the page size. Is this the case that you are concerned about?
We could also optimize the case for when a filter has not been specified and the last page is returned.
You could add a local count that returns a Promise to override the invoke, however, this change is something that would be better implemented in the JSDO code, specifically in the code that interacts with the Kendo UI DataSource (you can search for countFnName to see where it is used).
In the future we may return the count with a response for read.
Since the JSDO is open source, you could use GitHub or the regular channels for submitting an enhancement request.
Thank you and regards.
Flag this post as spam/abuse.
Hello Mike,
Great. We are on the same page.
I wonder if you would be willing to try some few *unofficial* lines of code in your environment.
I will suggest to include this code in a future release.
If so, here are some few lines of code that does what you are looking for.
Notice the line that tests for options.data.skip. You can find this section by searching for countFnName:
if (options.data && options.data.take) {
if (!this.readLocal &&
transport.countFnName !== undefined &&
typeof(jsdo[transport.countFnName]) === "function") {
if (options.data.skip === 0 &&
options.data.take > data.data.length) {
options.success(data);
return;
}
// Reuse filter string from the request.objParam object from fill() call.
promise = jsdo.invoke(
transport.countFnName,
{ filter: request.objParam.filter });
/*jslint unparam: true*/
promise.done(function(fnName, jsdo, success, request){
var exception, total;
Please let me know if this works for you.
I hope this helps.
Thanks.
Looks promising. Will try that out ASAP!
Hi Edsel, seems to do what it should :-)
Hello Mike,
Great. Thank you for trying the fix.
I see the pull request with this change and the correction to the header.
We will process the pull request for a future version.
Best regards.