: I think thats the case - I'm not seeing the problem - though I didn't
: follow your steps exactly, because I also set the data dir.
yeah ... i went back and tested again and verified that's what was
happening.
There is a bug with Luke when viewing "binary" based fields
introduced in Solr 1.4
Chris Hostetter wrote:
> : expected (not optimal... but an index/schema mismatch). If you're
> : using the 1.3 configs in 1.4 and getting an exception... that would be
> : very bad. Is that the case?
>
> as far as i can tell: yes. running 1.4 with the 1.3 example configs and
> an existing 1.3 i
: expected (not optimal... but an index/schema mismatch). If you're
: using the 1.3 configs in 1.4 and getting an exception... that would be
: very bad. Is that the case?
as far as i can tell: yes. running 1.4 with the 1.3 example configs and
an existing 1.3 index seems to be an instant NPE..
On Fri, Nov 13, 2009 at 8:05 PM, Chris Hostetter
wrote:
> : I tied to reproduce this in 1.4 using an index/configs created with 1.3,
> : but i got a *different* NPE when loading this url...
>
> I should have tried a simpler test ... iget NPE's just trying to execute
> a simple search for *:* when
: I tied to reproduce this in 1.4 using an index/configs created with 1.3,
: but i got a *different* NPE when loading this url...
I should have tried a simpler test ... iget NPE's just trying to execute
a simple search for *:* when i try to use the example index built
in 1.3 (with the 1.3 co
: > FWIW: I was able to reproduce this using the example setup (i picked a
: > doc id at random) �suspecting it was a bug in docFreq
:
: Probably just a null being passed in the text part of the term.
: I bet Luke expects all field values to be strings, but some are binary.
I'm not sure i follow
On Fri, Nov 13, 2009 at 5:41 PM, Chris Hostetter
wrote:
> : I'm seeing this stack trace when I try to view a specific document, e.g.
> : /admin/luke?id=1 but luke appears to be working correctly when I just
>
> FWIW: I was able to reproduce this using the example setup (i picked a
> doc id at rand
: I'm seeing this stack trace when I try to view a specific document, e.g.
: /admin/luke?id=1 but luke appears to be working correctly when I just
FWIW: I was able to reproduce this using the example setup (i picked a
doc id at random) suspecting it was a bug in docFreq when using multiple
s
I played around with it and am also getting a NullPointerException on Solr
1.4, as well (albeit with a slightly different dump). Some of my documents
actually return, FYI, just not all. I'm on a on a multi-solr-core system
searching /solr/core1/admin/luke?id=MYID. My Exception looked different,
