Announcement

**Isomorphic** · 14 Jul 2015, 01:30

The bugfix you mention in your question corrects a problem whereby the "skipRowCount" setting was not always applied correctly. Now that it is being applied correctly, the system is warning you that you may have a problem: as the message says, your DSRequest is asking for a paged dataset but without issuing a rowcount query, which will lead to the client treating the first page of data as if it is the entire dataset.

This will not be a problem for you if the entire dataset fits into one page anyway (unless you have changed it, a page is 75 records). But to get rid of the warning and ensure you don't start having problems if your datasets go above one page in size, you should use a different SQLPagingStrategy

**leeyuiwah** · 14 Jul 2015, 04:54

Thanks for your response.

However, I don't understand why the warning is necessary. I review the all four of SQLPagingStrategy enum values, but sqlLimit is indeed what we intend to do. I am specifying startRow and endRow in my query. (See background below)

I don't need the row count because I already know the count (obtained in a previous query).

Do you think the warning can be suppressed (or be changed to DEBUG level)? I think if someone is skipping row count then they probably know what they are doing and do not require the warning.

Background: I need to do all this (counting the number of row myself, and then issuing fetch with startRow and endRow (with skipRowCount)) just to overcome the built-in heuristic of the last page being "expanded forward". See the discussion here:

http://forums.smartclient.com/showthread.php?t=27727&page=2

**Isomorphic** · 14 Jul 2015, 15:07

The warning is necessary because, if you are using skipRowCount, you never want sqlLimit - it has no effect. sqlLimit implies that we generate SQL that constrains the selected rows to some subset of the total resultset. We can only do this if we have been able to establish the total resultset size with a rowcount query: otherwise, we might attempt to select a subset that is entirely outside the total set - for example, rows 76-150 of a resultset that actually only contains 30 rows. This leaves us with no sensible way to set the "totalRows" property, which in turn will lead to client components confused about how many records they are dealing with, and the possibility of undesirable behavior like a client component repeatedly requesting a range of rows that does not exist.

So, OK, in your case you have established the total resultset size by hand, and will never ask for rows outside that total size, but we don't have a mechanism for allowing client code to specify that kind of manual rowcount. We can't, because we couldn't trust it to be correct: your manual count might be perfect, but something could have added or removed rows in the meantime.

So, if skipRowCount is true, we always establish the total rowcount by selecting every row that matches the current criteria, and so sqlLimit is always wrong. The best alternative in your circumstances is probably "jdbcScroll"

We hope this explanation helps
Isomorphic Software Support

**leeyuiwah** · 14 Jul 2015, 15:15

I don't know under what circumstance one would use skipRowCount if they don't already have (or think they have) the exact row count somehow. But I can understand that you want your code to be safe.

I have suppressed the warning by setting the file log4j.isc.config.xml -- with the draw back that I now lost all other warning messages from the same sub-system. I guess I will have to live with that unless you change your mind.

Code:

<category name="com.isomorphic.sql.SQLDataSource">
    <priority value="ERROR" />
</category>

Thanks anyway!

Announcement

After 5.0-p20150628, got warning of "custom operation ... sqlLimit paging"

Comment

Comment

Comment

Comment