php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #58536 SetLimits uses wrong parameter ordering
Submitted: 2009-02-05 10:55 UTC Modified: 2009-02-05 13:01 UTC
From: ash at ewelike dot com Assigned:
Status: Not a bug Package: sphinx (PECL)
PHP Version: 5.2.5 OS: OS X Tiger
Private report: No CVE-ID: None
View Developer Edit
 [2009-02-05 10:55 UTC] ash at ewelike dot com 
Description:
------------
Calling $sphinxClient->setLimits(0, 10) should return 
(maximum) of 10 results, but in fact returns an error:

"per-query max_matches=0 out of bounds (per-server 
max_matches=1000)"

The PECL documentation at php.net/sphinxclient.setlimits shows 
the order is ($offset, $limit, ...) but it's being treated as 
($limit, $offset, ...)

The documentation order ($offset, $limit) is consistent with 
the pure PHP SphinxClient, and as the pecl package aims to be 
API compatible, the PECL client should change to honour the 
documented parameter order.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-05 11:15 UTC] ash at ewelike dot com 
The parameter ordering is correct (and consistent)- I 
misinterpreted the results caused by this bug:

See http://sphinxsearch.com/bugs/view.php?id=208
 [2009-02-05 11:26 UTC] tony at daylessday dot org 
max_matches is third parameter of setLimits() and it's 0 by default.
There is nothing wrong with the order of parameters, they're passed just as the documentation says.
 [2009-02-05 13:01 UTC] ash at ewelike dot com 
The default max_matches value of '0' is handled badly 
(causing an error.)

I see you (Tony) have a patch attached to the sphinxsearch 
bug - the patch looks good (matching the pure PHP client) 
and getting the fix into a new PECL build would fix the 
problem reported here (despite the misleading summary.)
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jan 15 11:01:31 2025 UTC