It's not expected behaviour, it's a bug in the batch inserting code which I introduced when meddling with ValueContext.numeric behaviour. I'm planning to get rid of that ValueContext thing and instead, when indexing a number, index that in lucene as a string (just as usual) _and_ numerically (for optimized/cool number range queries). Hopefully next milestone. But for now I'll fix this bug.
2011/2/24 Craig Taverner <[email protected]>: > Hi, > > I have found a surprising behavior in the BatchInserterIndex in the new 1.3 > series. If I want to index a non-string: > > // Index node > Map<String, Object> props = new HashMap<String, Object>(); > props.put( "key", 123L ); > index.add( id, props ); > index.flush(); > > // Search for node > IndexHits<Node> result = index.get("key", 123L); > //result.size() => 0 > > The above code always returns an empty result set. But if instead we add the > value as a string, but still search for an integer, we get a result. > > // Index node > Map<String, Object> props = new HashMap<String, Object>(); > props.put( "key", Long.toString(123L) ); > index.add( id, props ); > index.flush(); > > // Search for node > IndexHits<Node> result = index.get("key", 123L); > //result.size() => 1 > > This seems rather surprising to me. I would not have been surprised if the > opposite was true, but this way round was unexpected. > > Is this correct behavior? And if so, why? > > Regards, Craig > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
