Paging support for service persisted classes. (Offset paging)

[Rob Duda]

I have been working with the grid control and playing around with the paging setting. I’ve noticed that while the framework seems to make the correct calls through the read, the client side is still expected a fully loaded read, (0 through (offset + count)). If I only pass a collection that is of the count size. I only get the last element of the collection for the next page.

The problem is that if I attempt to page past a page that is greater than the read limit I will get an error from the framework. Is this expected behavior or a bug?

I’ve written a class that can be used to illustrate the problem and can attach it but the code is easy to create from scratch:

Create a class, set it’s persistence to Service. Add a key of type integer. In the read add one ‘blank’ clause and add this code:

(logger’info associations attributes class offset count orderBy properties where xlock)
(lambda(yield)
(let ((result (collection)))
(for
((i 0))
(< i 20000)
(++ i)
(result’add (message (: :oid (oid i)) (: item (format “item {0}” i))))
)
(logger’info result)
(for-each
yield
result)
)
)

I can do a read from the console with this script and I do not get the read limit error but from the UI I do:

(for-each-page OffsetExample ‘(item) ‘() ‘() 20000 10 #f
(lambda(item)
(logger’info (item’item))
)
)

The console code above seems to suggest that even though I am returning the entire collection (20000 items) a ‘cursor’ is still being used to page through. If I take out the yield function and just return the collection the above code does indeed error out as I would expect. (with the read limit error)

Just for the record, here is the logging output from the UI: (rows set to 1000)

First read: 2016-05-16 10:21:46 [nexj.core.persistence.virtual.VirtualAdapter.OffsetExample] [INFO] [http:10.66.120.157:59989 nexjsa] () (item) # 0 1001 (((@) . #t)) #<{}> () #f

Second read: 2016-05-16 10:21:53 [nexj.core.persistence.virtual.VirtualAdapter.OffsetExample] [INFO] [http:10.66.120.157:59989 nexjsa] () (item) # 1000 1001 (((@) . #t)) #<{}> () #f

Third read: 2016-05-16 11:05:17 [nexj.core.persistence.virtual.VirtualAdapter.OffsetExample] [INFO] [http:10.66.120.157:60292 nexjsa] () (item) # 2000 1001 (((@) . #t)) #<{}> () #f

Forth read: 2016-05-16 11:10:27 [nexj.core.persistence.virtual.VirtualAdapter.OffsetExample] [INFO] [http:10.66.120.157:60292 nexjsa] () (item) # 3000 1001 (((@) . #t)) #<{}> () #f

Fifth read: This one errors out on the UI with read limit error

0

[norairn]

At the moment service persistence does not fully support offset paging and applies offset to every recordset. This is in our backlog.  The CRM application uses bookmark paging and that has been our focus.

May I suggest using bookmark paging between the UI and the service persistence. Download the attached files and put the BookmarkTest.meta under /classes, Service.form under /forms, and Service.screen under /screens folders.

Run the BookmarkTest portlet with the following URL: http://localhost:7080/nexj/SysPortletServer/Service.htm. Replace “localhost:7080/nexj” with a different server root if necessary.”

1

Attachments:

You must be logged in to view attached files.

[Rob Duda]

In other places we already use bookmark paging but it is much easier with filters if offset paging was supported. With filters you cannot always guarantee uniqueness and we don’t always want our services to expose internal id’s as these tend to get embedded into multiple systems and become a maintenance problem. Thanks for your response, we look forward to the day when this is fully supported by the framework.

0

[Author]

Posts