On Fri, Jun 27, 2014 at 1:47 AM, Elliot Ickovic <elliot.icko...@gmail.com>
wrote:
> Tried the following:
>
> add() - fakeparent000 : [single001] //with new 'doc-type:fakeparent'
>
here it should be doc-type:parent, if you wish to distinguish "fakes", mark
them by the separate field.
mind that you should not use the differentiatior bitset {!
...of='doc-type:parent'} for the actual filtering/selecting, it should be
always the same constant filter which carries your document structure.
Filter by left side of query.
add() - parent001 : [child001_1, child001_2]
> commit()
>
> Then query:
>
> {!child of='doc-type:parent'}doc-type:parent
>
> response now contains *fakeparent000*, *single001*, child001_1, child001_2
> should only contain child types.
>
> also tried with
> add() - single001 : [fakechild001_1]
> ...
> with similarly incorrect response.
>
> Any idea could be going wrong?
>
>
>
> On Thu, Jun 26, 2014 at 3:41 PM, Elliot Ickovic <elliot.icko...@gmail.com>
> wrote:
>
> > Hi Mikhail, Thank you for the quick response!
> >
> > If I instead of:
> >
> > add() - fakeparent000 : [single001]
> >
> > I do :
> >
> > add() - single000 : [fakeChild001]
> >
> > will this prevent the index from appearing corrupted? This way I can
> > retain my logical top level docs.
> >
> > What is the reason I need add a fake doc? If I add nested documents N
> > levels deep, creating a tree, do I need to ensure fake documents are
> > created to tree max depth? Or is it sufficient only for the top level?
> >
> >
> > On Thu, Jun 26, 2014 at 2:12 PM, Mikhail Khludnev <
> > mkhlud...@griddynamics.com> wrote:
> >
> >> Hello Elliot,
> >>
> >> Parent doc is mandatory, you can't omit it.
> >> Thus instead of:
> >> add() - single001
> >>
> >> you have to
> >>
> >> add() - fakeparent000 : [single001]
> >>
> >> there was no plans to support any sort of flexibility there...
> >>
> >>
> >>
> >> On Thu, Jun 26, 2014 at 9:52 PM, Elliot Ickovic <
> elliot.icko...@gmail.com
> >> >
> >> wrote:
> >>
> >> > Using Solr 4.8.1.
> >> >
> >> > I am creating an index containing Solr documents both with and without
> >> > nested documents. When Indexing documents from a single SolrJ client
> >> on a
> >> > single thread if I do not call commit() after each document add() I
> see
> >> > some erroneous documents returned from my "child of" or "parent which"
> >> > block queries. Here is an example:
> >> >
> >> > I have a required field 'doc-type' used for the block join. For
> >> example I
> >> > have 3 types {'parent', 'child', 'single'} where parent has 1 or more
> >> > nested child docs and single never has a nested doc.
> >> >
> >> > CASE 1:
> >> > ================================
> >> > I add / commit docs in this order
> >> >
> >> > add() - single001
> >> > add() - parent001 : [child001, child002]
> >> > commit()
> >> >
> >> > then query all child docs of every parent doc
> >> >
> >> > ..... {!child of='doc-type:parent'}doc-type:parent
> >> >
> >> > response contains *single001*, child001, child002 -- INCORRECT
> >> *single001
> >> > *is
> >> > not a child.
> >> > ================================
> >> >
> >> > CASE 2:
> >> > ================================
> >> > I add / commit docs in this order
> >> >
> >> > add() - single001
> >> > *commit() added commit here*
> >> >
> >> > add() - parent001 : [child001, child002]
> >> > commit()
> >> >
> >> > then query all child docs of every parent doc
> >> >
> >> > ..... {!child of='doc-type:parent'}doc-type:parent
> >> >
> >> > response contains only {child001, child002} -- CORRECT
> >> > ================================
> >> >
> >> > CASE 2 will only work when a single solr client is adding docs. If
> >> spawn
> >> > a bunch of threads that do adds I will not be able to guarantee that
> >> commit
> >> > is called between adds.
> >> > Additionally, I am not 100% sure calling commit() is the correct
> >> solution
> >> > it just seems to work where I have tested.
> >> >
> >> > I'd greatly appreciate if someone can shed some light on this problem
> or
> >> > help me better understand the limitations of the block indexing and
> >> block
> >> > join.
> >> >
> >>
> >>
> >>
> >> --
> >> Sincerely yours
> >> Mikhail Khludnev
> >> Principal Engineer,
> >> Grid Dynamics
> >>
> >> <http://www.griddynamics.com>
> >> <mkhlud...@griddynamics.com>
> >>
> >
> >
>
--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics
<http://www.griddynamics.com>
<mkhlud...@griddynamics.com>
