Well, it is embarrassing. After several days of on and off poking
around, I figured it out. It turns out that if the case of the field
name you use in both mapping and query does not match the case of the
"same" name in the json with the data, the "mapped" field stays empty
and searches against it come back empty too.
Lesson learned. But to make it easier on other people - would it make
sense to introduce a way to make upload "strict" - meaning that all
fields in the data json have to be mapped upfront. That's the mode I
would use and it would definitely save me some grief.
On Aug 22, 1:50 pm, Shay Banon kim...@gmail.com wrote:
The format that you use is not affected by the mentioned problem (but, you
should upgrade in any case to latest). Back to your question, can you post a
simpel recreation of what does not work? If you index a field
with the yyyy-MM-dd format, it will automatically be detected as date type,
so you don't even need to explicitly specify it as date. Also, when working
with dates, there isn't really a meaning for an analyzer.
On Mon, Aug 22, 2011 at 6:43 PM, Michael Feingold mfeing...@hill30.comwrote:
I am currently on 0.17.2. Which one should I be using?
On Aug 22, 2:03 am, Alex Vasilenko aa.vasile...@gmail.com wrote:
There was a fix in 0.17.6 -
Please specify the version, you're using.
2011/8/20 Michael Feingold mfeing...@hill30.com
Is there a trick to making date field work? I tried a few things to no
avail here is what I tried:
- I mapped the field specifying field type as "date" - no explicit
definition for analyzer. I indexed a few records with the date
formatted as yyyy-mm-dd and I tried to run both term and text queries
providing date in the same format. Again without explicitly specifying
the analyzer. Both queries came back empty even though when I pulled
the documents using queries based on different fields I can see the
date is there
- I did pretty much the same but changed the field type to "string"
with the same result.
What am I missing here?