Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Pagination - Dealing with large data sets(Looking for examples or recipes for dealing with large data sets in Scout)
Pagination - Dealing with large data sets [message #1066217] Mon, 01 July 2013 15:03 Go to next message
Jason Fauble is currently offline Jason FaubleFriend
Messages: 10
Registered: June 2011
Location: Tallahassee, Florida
Junior Member
Are there any examples, recipes, or best practices when dealing with large data sets in a Scout application? It does not appear that the table pages in Scout supports paging. I have searched the Scout forum and otherwise, but have not seen anything.
Re: Pagination - Dealing with large data sets [message #1066704 is a reply to message #1066217] Wed, 03 July 2013 21:12 Go to previous messageGo to next message
Claudio Guglielmo is currently offline Claudio GuglielmoFriend
Messages: 128
Registered: March 2010
Senior Member
Hi there

In our projects we typically limit the number of rows by defining a max row count. If the limitation is reached a message is displayed at the bottom of the table with the use of ITable#setTablePopulateStatus, see screenshot.

index.php/fa/15467/0/

To show the other rows the user has to adjust the search criteria.

Concerning the paging you're right, the scout table does not support paging. For the mobile ui I once made an extension of the scout table and added basic paging functionality. But it's limited to a list widget (not table) and rap ui. Also, it's implemented on client side only, so all rows are transferred from server to client.
It probably won't help you but if you are interested, have a look at https://eclipse.googlesource.com/scout/org.eclipse.scout.rt/+/master/org.eclipse.scout.rt.client.mobile/src/org/eclipse/scout/rt/client/mobile/ui/basic/table/IMobileTable.java and https://eclipse.googlesource.com/scout/org.eclipse.scout.rt/+/master/org.eclipse.scout.rt.ui.rap.mobile/src/org/eclipse/scout/rt/ui/rap/mobile/form/fields/tablefield/RwtScoutMobileListModel.java.

Best regards
Claudio
  • Attachment: result.png
    (Size: 6.09KB, Downloaded 471 times)
Re: Pagination - Dealing with large data sets [message #1066727 is a reply to message #1066704] Thu, 04 July 2013 06:37 Go to previous messageGo to next message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 346
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Claudio Guglielmo wrote on Wed, 03 July 2013 23:12
In our projects we typically limit the number of rows by defining a max row count. If the limitation is reached a message is displayed at the bottom of the table


I know you can limit the number of returned results in SQL using "LIMIT". But how do you check if the limitation is reached? Just check if the number of returned records is the same as the limit? If so, how do you distinguish between the case where the query returns exactly the limited number of records (in which case nothing more could be gotten) with the case where there are more than the limited number of records?

Or do you just accept this case as an improbable edge case?
Re: Pagination - Dealing with large data sets [message #1070728 is a reply to message #1066727] Thu, 18 July 2013 14:47 Go to previous messageGo to next message
Andreas Hoegger is currently offline Andreas HoeggerFriend
Messages: 178
Registered: February 2010
Senior Member
Paging support of Eclipse Scout.
Scout servers consist basically out of a set of stateless services. To keep the memory footprint low stateless is a must for huge Scout applications. Paging support would require stateful services and furthermore a sorting and filtering of table entries (which is a out of the box functionality of Scout) would not anymore be possible or at least these operations would come up with not understandable results.


Edge cases of result sets:
Urs you are right at the moment the only indicator a LIMIT is reached is the number of rows in the result set. Happy news for the upcoming Luna release. Scout gets read of the last untyped service results. So with Luna the table page services will use as well a FormData as a data transfer object as every other service does.

In case you already implemented your own DTO's you are today able to bring the flag (reached row number limit) to the client.

-andreas
Re: Pagination - Dealing with large data sets [message #1076451 is a reply to message #1070728] Wed, 31 July 2013 12:16 Go to previous messageGo to next message
Chris Snow is currently offline Chris SnowFriend
Messages: 50
Registered: December 2011
Member
I'm a bit confused, I thought pagination was a must have for this type of framework? This isn't just a large dataset problem. Sending any more than 50 records to a client at a time is excessive.

The approach of limiting the rows doesn't make sense to me unless you limit to about 20 rows. Returning more than 20 rows to a mobile app client could result in a lot of the user's bandwidth allowance being used up?

How does BSI's CRM product deal with large data sets?



[Updated on: Thu, 01 August 2013 06:30]

Report message to a moderator

Re: Pagination - Dealing with large data sets [message #1077075 is a reply to message #1076451] Thu, 01 August 2013 08:02 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 817
Registered: October 2011
Senior Member
The process is exactly like you described:

With a search form, we reduce the "rows" coming back from the data storage (== database in the majority of cases). If we know there will be a lot of rows we force the used to do this first step. I have seen a project querying a legacy mainframe system. In this case the restrictions (combination of mandatory fields) in the search form were big.
After that if the user still get a lot of rows coming back from its search query, he can filter them in the client: please notice that this is an client-side/UI operation only (rows are hidden given the filter states)

Even a product like BSI CRM is fine with this approach. User experience is good (search and filter are accepted mechanism. For the search the trend is to have a single text field where you can query everything - "the google way"). From a technical point of the view the constraints explained by Andreas are respected.

With mobile, I agree that it looks like a little bit different. I do not know this domain well, but I assume that this is why Claudio has implemented a pagination mechanism (but this is a RAP-Mobile component only).

I hope it helps.
Re: Pagination - Dealing with large data sets [message #1077492 is a reply to message #1077075] Thu, 01 August 2013 19:56 Go to previous messageGo to next message
Chris Snow is currently offline Chris SnowFriend
Messages: 50
Registered: December 2011
Member
Makes perfect sense - thanks Jeremie!
Re: Pagination - Dealing with large data sets [message #1132714 is a reply to message #1070728] Fri, 11 October 2013 10:43 Go to previous message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 817
Registered: October 2011
Senior Member
Andreas Hoegger wrote on Thu, 18 July 2013 16:47
Edge cases of result sets:
Urs you are right at the moment the only indicator a LIMIT is reached is the number of rows in the result set. Happy news for the upcoming Luna release. Scout gets read of the last untyped service results. So with Luna the table page services will use as well a FormData as a data transfer object as every other service does.


We are working on TablePageData for Luna M3:
* Shared: Bug 412752
* SDK: Bug 418997
* Client: Bug 419138
* Server (SQL Service): Bug 419140 (work in progress)

I assume we will need to start a new wiki page:
http://wiki.eclipse.org/Scout/Concepts/TablePageData

Here the corresponding New and Noteworthy entry for M3

We appreciate to get early feedback on this modifications (let say when M3 is out).

.

[Updated on: Fri, 11 October 2013 11:01]

Report message to a moderator

Previous Topic:Set size of a form
Next Topic:JasperReport Dependencies
Goto Forum:
  


Current Time: Fri Dec 19 13:43:30 GMT 2014

Powered by FUDForum. Page generated in 0.01897 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software