[Question] How does JSDO work with server pagination?

[W1nstar]

This may be an issue, but I can't say exactly.

I'm using skip and top as parameters on my read operations in order to always ask the server for the 10 records the user asked for. I'm always getting the next 10 records correctly.

The problem is the JSDO doesn't hold the previous 10 records, hence CRUD operations fail for those records. To try and circumvent this issue I tried to use the different mergeModes that can be specified for the fill operation, but I'm having problems:

1. For some reason it does not order the records
2. I have to manually clear JSDO records, but I haven't find a way to do so in the docs.
3. If the catalog holds more than one dataSet, it does not merge.

I've read on the docs that Kendo objects work with server paging, so I assumed JSDO was the one doing the work. After debuggin the whole process I'm about to say it doesn't, but I'd like official confirmation.

[edselg]

I am assuming that you are using Kendo UI for jQuery/AngularJS.

Here is some feedback.

The problem is the JSDO doesn't hold the previous 10 records, hence CRUD operations fail for those records.

Yes, the current implement to support paging with Kendo UI is to read into the JSDO memory the records that are requested by the Kendo UI DataSource.

At one point we consider a functionality where the JSDO memory would cache previous records. However, this is not available.

To try and circumvent this issue I tried to use the different mergeModes that can be specified for the fill operation, but I'm having problems:

Working with the mergeModes is a way to do the work.

I think depending on your requirements, you could use the readLocal functionality on the JSDO.
You would read the records from the server and the Kendo UI DataSource would receive the 10 records but they would be coming out of the JSDO memory locally rather than doing a new JSDO read() which replaces the records.

Please let me know if you are interested on this and I can provide details.

For some reason it does not order the records

Is this a result of using the mergeModes or of the records sent over the network?

When working with records on the network, something to consider is that records would be sorted by the primary index of the temp-table. (That is why when implemeting the JFP, we add a seq field.)

If it is a result of the merge, perhaps, you could try the autoSort option of the JSDO.

I have to manually clear JSDO records, but I haven't find a way to do so in the docs.

You could use addRecords() with MODE_EMPTY and an empty dataset:

• jsdo.eCustomer.addRecords({}, progress.data.JSDO.MODE_EMPTY)
• jsdo.addRecords({}, progress.data.JSDO.MODE_EMPTY)

The addRecords() method is valid at the jsdo instance if there is only one temp-table.

If the catalog holds more than one dataSet, it does not merge.

If you are using addRecords() and seeing issues merging perhaps, it is the syntax what parameter you pass which does not have the expected structure.

I've read on the docs that Kendo objects work with server paging, so I assumed JSDO was the one doing the work. After debuggin the whole process I'm about to say it doesn't, but I'd like official confirmation.

When working with the JSDO + Kendo UI for jQuery/AngularJS and using serverPaging true, the JSDO performs the interaction with the data service. the Kendo UI DataSource passes the requests to the JSDO which then uses the JFP to get the desired records from the server.
Please provide more info on what you are expecting and not seeing happening.

I hope this helps.

[W1nstar]

Thanks for the fast reply!

I am not using Kendo. I'm using plain JS on browsers and ReactNative on apps. The user is seeing lists, that I load 10 record at a time. There's no real pagination that the user can control and see only 10 records each time, scrolling down. He sees an ever growing list of records. He can order the list however he wants, but every time it changes, he gets the first 10, and has to scroll down if he wants more.

When he has, say, 70 records, only records from 60 to 70 are hold in the JSDO memory, since are the last requested... therefore only those last 10 records are working with standard CRUD jsdo operations. The other ones fail, since they are not found in JSDO memory.

Initially I thought of read/save local, and also I noticed the getData function uses a param object that accepts sort, skip and top... But I was doing reads of thousands of records and load times are an issue for this project, so I ditched it. Having to do an initial read of every record in a table is not an option.

After reading the docs and bathing into the classes I found the mergeModes, and set different types of mergemodes on my read operation. After including the JSDO_MERGE mergeMode property on the param object for the fill operation, it began to correctly accumulate records in memory and the CRUD operations worked, but it didn't sort them, and it didn't clear the memory when the filter changed. It's getting the next 10 records from the server sorted OK, but after the merge they aren't sorted.

I use it like this:

		let obj = { filter: filter, sort: sort, skip: skip, top: top, mergeMode: progress.data.JSDO.MODE_MERGE }
		let data = []
		let count = 0
		try {
			data = await this._JSDOs[name].fill(obj)

progress.data.JSDO.MODE_MERGE equals to an integer value of 3, so I'm guessing the syntax is ok.

For the clear records in memory part: imagine I'm seeing a customer list wich is filtered by customer.groupCategory, and I want to see a different groupCategory... with JSDO_MERGE I was seeing customers from the previously seen category. I had to manually clear the records from the jsdo._data property depending on what changes were done to the filter, while I expected the JSDO to do that.