MAX ROWS with offset

[bit-forge]

Murphy's Law is in play, and my RETS server has a result set that returns a total set size that is an exact multiple of MAX ROWS. So, MAX ROWS is 500, and the total result set is 2000, necessitating four batches in SearchQuery. The problem is that on the last batch, MAX ROWS is set by the server, but it's also the last possible result set because and offset value of 2001 will return an offset error from the RETS server. Based on how maxrows_reached is set, the query always errors out with this data set, because it always tries to request one more batch than necessary.

My rather ham-fisted fix is:

if (isset($xml->MAXROWS)) {
// MAXROWS tag found. the RETS server withheld records.
// if the server supports Offset, more requests can be sent to page through results
// until this tag isn't found anymore.
if(isset($xml->COUNT)) {
// Check to see if this is the last batch based on the total size of the result set. Server may set MAX ROWS even if this
// batch is the last possible set, if the total records found is perfectly divisible by max rows.
if($this->NumRows($this->int_result_pointer) < $this->search_data[$this->int_result_pointer]['total_records_found']) {
$this->search_data[$this->int_result_pointer]['maxrows_reached'] = true;
}
} else {
$this->search_data[$this->int_result_pointer]['maxrows_reached'] = true;
}
}

Not knowing enough about the internals of phRETS I didn't want to do a pull request, as I thought this is probably not the optimal solution.

[imcjeff]

We're currently running into problems with this same error ([Offset] is beyond the number of returnable records.). Where would I go about implementing the solution in this post? Or, is there another workaround for this problem that's come up since this was first posted?

[troydavisson]

With 2.x, it includes the ability to override the logic used to determine when to continue pagination. If instances where someone is interacting with a non-compliant server, that logic can be changed to support a different algorithm.