|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2008-10-06 10:30 UTC] brianlmoon@php.net
Description:
------------
Sphinx servers compiled with --enable-id64 are capable of storing 64 bit integers for document ids. The PECL client wraps those ids into negative numbers. The PHP class that comes with sphinx preserves those values, even on 32-bit client hardware.
Reproduce code:
---------------
$cl = new SphinxClient();
$cl->SetServer( SPHINX_PRODUCT_DATA_SERVER, 3312 );
$cl->SetLimits( $start, $limit, 1000 );
$res = $cl->Query( $keywords );
print_r($res);
Expected result:
----------------
Result using packaged PHP class:
[matches] => Array
(
[415000000260] => Array
(
[weight] => 2
[attrs] => Array
(
[vendor_id] => 415
)
)
[415000001443] => Array
(
[weight] => 2
[attrs] => Array
(
[vendor_id] => 415
)
)
Actual result:
--------------
Example print_r of sphinx result from PECL:
[matches] => Array
(
[-1611827452] => Array
(
[weight] => 2
[attrs] => Array
(
[vendor_id] => 415
)
)
[-1611826269] => Array
(
[weight] => 2
[attrs] => Array
(
[vendor_id] => 415
)
)
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Nov 02 10:00:02 2025 UTC |
Tested it on two systems but I think my issue is slightly different. Looking at brianlmoon at php dot net in a little more detail he was having a problem with the ID's. The problem I am having still are with attribute values > 32bit. The native PHP sphinx library works fine however I am still getting negative values for attributes just like he was getting for ID's. From "$ php -i": ---------------- sphinx support => enabled Version => 0.2.0 Revision => $Revision: 1.13 $ Expected result: ---------------- [matches] => Array ( [0] => Array ( [id] => 20080995581 [weight] => 1 [attrs] => Array ( [term_code] => 200809 [crn] => 95581 [class_code] => 1777078230 [class] => 1862662430 [subj_code] => 1295937198 [crse_numb] => 1050 [start_date] => 1226757600 [end_date] => 1227376500 [ssts_code] => 2147483647 [edtogo_code] => 0 [order_title] => 506 [audiences] => Array ( [0] => 2775031812 ) [categories] => Array ( [0] => 929050978 [1] => 4091002307 ) ) ) ) Actual result: -------------- [matches] => Array ( [0] => Array ( [id] => 20080996352 [weight] => 1 [attrs] => Array ( [term_code] => 200809 [crn] => 95581 [class_code] => 1777078230 [class] => 1862662430 [subj_code] => 1295937198 [crse_numb] => 1050 [start_date] => 1226757600 [end_date] => 1227376500 [ssts_code] => 2147483647 [edtogo_code] => 0 [order_title] => 506 [audiences] => Array ( [0] => -1519935484 ) [categories] => Array ( [0] => 929050978 [1] => -203964989 ) ) ) )No luck. Also there is a typo in the patch. line 32 of patch file find: sizof replace: sizeof One more strange thing is that on the FreeBSD 7 system I get a slightly different result (see ssts_code attr). But I ran this patch also on a CentOS4 system and I get the same result with a correct ssts_code value. If there is anything else I can try to help figure out this bug please let me know. FreeBSD 7 Result: ----------------- [matches] => Array ( [0] => Array ( [id] => 20080996352 [weight] => 1 [attrs] => Array ( [term_code] => 200809 [crn] => 95581 [class_code] => 1777078230 [class] => 1862662430 [subj_code] => 1295937198 [crse_numb] => 1050 [start_date] => 1226757600 [end_date] => 1227376500 [ssts_code] => -740712821 [edtogo_code] => 0 [order_title] => 506 [audiences] => Array ( [0] => -1519935484 ) [categories] => Array ( [0] => 929050978 [1] => -203964989 ) ) ) )