Re: [searchisko-dev] How to represent this as a query

This should be fine for now, but it’s going to produce bugs before too long. On 3 Apr 2014, at 14:31, Lukas Vlcek <lvlcek(a)redhat.com&gt; wrote: > Hi Pete, > > You can use: > accounts.username:pmuir AND accounts.domain:"vimeo.com" > > but there are some gotchas: > > Imagine the following document: > > { > displayName: "Pere Muir", > accounts: [ > {username: "pmuir", domain: "vimeo.com"}, > {username: "petemuir", domain: "youtube.com"} > ] > } > > When this is indexed then it is transformed to the following document (at > Lucene level): > > { > displayName: "Pete Muir", > accounts.username: ["pmuir","petemuir"], > accounts.domain: ["vimeo.com","youtube.com"] > } > > Both 'accounts.username' and 'accounts.domain' is name for a field name - > it just contains a dot, there is no notion of "nestedness" in it at Lucene > level. > At this point you can notice that we lost connection between username and > domain. We do not know which username belong to which domain. > This means we can have query: > > accounts.username:petemuir AND accounts.domain:"vimeo.com" > > and it would result into the same document in spite of the fact that was no > account for vimeo.com having username petemuir. > > So the question is if this is a problem for you now or not. I can imagine > that you might be fine with how it works for now - it depends what you > exactly need to retrieve from the DCP. However, going forward we can > expose a query that would honour the "nestedness" because Elasticsearch > provides it [1]. > > Let me know if you have more questions. > > Regards, > Lukas Vlcek > jboss.org Development Team > > [1] > http://www.elasticsearch.org/guide/en/elasticsearch/reference/0.90/mappin... > > ----- Original Message ----- >> Hi, >> >> I have this piece of JSON, which maps to a contributor profile on the DCP: >> >> {:displayName=>"Pete Muir", :accounts=>[{"username"=>"pmuir", >> "domain"=>"vimeo.com"}]} >> >> How do I represent this as a query? I’m not sure how to represent the >> nested >> structure for the best... >> >> Thanks >> >> Pete