php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 08:01:28 2024 UTC