$response->response is null - unable to access docs or numFound

[GoogleCodeExporter]

All of the tutorials I have read show that this code should work for me:

$response = $solr->search($query, $start, $limit, $params);

if ($response->getHttpStatus() == 200) {
    if ($response->response->numFound > 0) {
        foreach ($response->response->docs as $doc) {
            echo $doc->title;
        }
    } else {
        echo 'Solr Search Found No Results<br>';
    }
}

However, the $response->response object is null.  If I var_dump($response) 
I can see the rawResponse and all the results it contains with no 
problems.  Trying $response->docs or $response->numFound returns those as 
both null as well.  What's the proper way to access the response from my 
queries?

Original issue reported on code.google.com by frozenso...@gmail.com on 9 Jul 2009 at 7:05

[GoogleCodeExporter]

Okay after a lot more debugging, I've realized that solr was indexing non 
integer 
data as an integer, and the json coming back didn't have quotes around the 
value.  
Thus, invalid json data was causing json_decode to return null in the 
_parseData 
function of the response.  

Perhaps it would be a good idea to check if the variable is null and throw an 
error 
if that's the case, to make issues like this easier to find?

Original comment by frozenso...@gmail.com on 9 Jul 2009 at 7:28

[GoogleCodeExporter]

Can you paste in, or attach an example of the var_dump($response) - i want to 
see the raw response that its 
apparently not parsing correctly. That will help me to figure out what might be 
going on here.  Thanks.

Original comment by donovan....@gmail.com on 9 Jul 2009 at 7:28

[GoogleCodeExporter]

Seems like a good idea, I'll put it in.

It'd be worth checking if this is an existing issue in Solr issue tracker. 
Since they're producing an invalid json 
response instead of throwing an exception themselves that the data didn't fit 
the data type. 

I know they check data vs. the schema's type at indexing time. Did you index it 
one way and then change the 
schema? Might be that they're inherently trusting that the data coming out of 
lucene will match the schema's 
defined data type in this case for performance (don't want to waste time 
checking it).

Original comment by donovan....@gmail.com on 9 Jul 2009 at 7:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Solr was definitely letting me put in the invalid data. I just double checked 
my 
build script.

I've also found an issue with floats that have a value of 0 being returned as 
.0, 
which is also causing json to fail.

Original comment by frozenso...@gmail.com on 9 Jul 2009 at 8:34

[GoogleCodeExporter]

I haven't found any think in the solr issue tracker that looks like your bug, 
so we might have something new 
here.  What version of solr are you using?

Original comment by donovan....@gmail.com on 9 Jul 2009 at 8:40

[GoogleCodeExporter]

1.3 stable.

Original comment by frozenso...@gmail.com on 9 Jul 2009 at 8:43

[GoogleCodeExporter]

I was able to reproduce your issue and I think I see where it comes from. My 
document looked like this:
{{{
$document = new Apache_Solr_Document();
$document->guid = 'meh';
$document->float = array(
        null,
        0,
        "0",
        ".0"
);
}}}

You'll see i'm passing different forms of "floats" to a multi-valued field.

 First I indexed the field as the predefined type "float" and found that it would take ANY value (similar to what 
you're seeing and not what i expected) - so I looked at the schema.xml file for 
what implementation it was 
using:
{{{
    <!-- numeric field types that store and index the text
         value verbatim (and hence don't support range queries, since the
         lexicographic ordering isn't equal to the numeric ordering) -->
    <fieldType name="float" class="solr.FloatField" omitNorms="true"/>
}}}
If you read the comment you'll see it takes any value without checking - but 
the JSON writer still expects it to 
be a proper numeric format (this seems like a bug to me, which I'll report).

So then I used the "sfloat" predefined type, which if we look:
{{{
    <!-- Numeric field types that manipulate the value into
         a string value that isn't human-readable in its internal form,
         but with a lexicographic ordering the same as the numeric ordering,
         so that range queries work correctly. -->
    <fieldType name="sfloat" class="solr.SortableFloatField" sortMissingLast="true" omitNorms="true"/>
}}}
This behaved exactly like i expected. At index time it threw an error back to 
me for the null value. When I 
removed the null from my code, all values were then output by the JSON writer 
as 0.0

So, i think your problems with integers and floats can be solved by using the 
sortable variants.

Original comment by donovan....@gmail.com on 9 Jul 2009 at 9:16

• Changed state: Accepted

[GoogleCodeExporter]

Good to see it's not just me. As for sint and sfloat I was under the impression 
that you couldn't access 
their orig value in that form... Because in Luke the values were all garbled.

My temp fix was to just not index 0.0 values as we don't use them. They're the 
same as null for us.

Original comment by frozenso...@gmail.com on 9 Jul 2009 at 9:34

[GoogleCodeExporter]

you can't necessarily get the exact value you put in, no (for example the ".0" 
was returned in numeric form "0.0") 
but you will get back a value in the solr response as long as your field 
definition is configured to store.  I think 
Luke is seeing whatever Solr's internal representation for floats / ints is - 
which I'm not very familiar with.

I created a solr issue, so we'll see what they have to say about the JSON 
writer's behavior: 
https://issues.apache.org/jira/browse/SOLR-1270

Original comment by donovan....@gmail.com on 9 Jul 2009 at 9:41

[GoogleCodeExporter]

Following the Solr issue, it seems that they are going with at output time 
checking of the float value. If it doesn't 
parse as a valid float then the JSON response will output a string value 
instead. They're also looking to apply this 
to their other numeric field types.

Since solr is now making a move on this, I'm going to close this issue.

Original comment by donovan....@gmail.com on 4 Aug 2009 at 6:17

• Changed state: Done

[GoogleCodeExporter]

unable to create index using php client

Original comment by aartyla...@gmail.com on 6 May 2011 at 9:05