Tried the following:

add() - fakeparent000 : [single001]     //with new 'doc-type:fakeparent'
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>
>>
>
>

Reply via email to