Listen to that advice. Denormalize, denormalize, denormalize. Think about the
results page and work backwards from that. Flat data model.
wunder
Search guy at Infoseek, Inktomi, Verity, Autonomy, Netflix, and Chegg
On Feb 18, 2014, at 7:37 PM, Jason Hellman <jhell...@innoventsolutions.com>
wrote:
> Thinking in terms of normalized data in the context of a Lucene index is
> dangerous. It is not a relational data model technology, and the join
> behaviors available to you have limited use. Each approach requires
> compromises that are likely impermissible for certain uses cases.
>
> If it is at all reasonable to consider you will likely be best served
> de-normalizing the data. Of course, your specific details may prove an
> exception to this rule…but generally approach works very well.
>
> On Feb 18, 2014, at 4:19 AM, Mikhail Khludnev <mkhlud...@griddynamics.com>
> wrote:
>
>> absolutely.
>>
>>
>> On Tue, Feb 18, 2014 at 1:20 PM, <m...@preselect-media.com> wrote:
>>
>>> But isn't query time join much slower when it comes to a large amount of
>>> documents?
>>>
>>> Zitat von Mikhail Khludnev <mkhlud...@griddynamics.com>:
>>>
>>>
>>> Hello,
>>>>
>>>> It sounds like you need to switch to query time join.
>>>> 15.02.2014 21:57 пользователь <m...@preselect-media.com> написал:
>>>>
>>>> Any suggestions?
>>>>>
>>>>>
>>>>> Zitat von m...@preselect-media.com:
>>>>>
>>>>> Yonik Seeley <yo...@heliosearch.com>:
>>>>>
>>>>>>
>>>>>> On Thu, Feb 13, 2014 at 8:25 AM, <m...@preselect-media.com> wrote:
>>>>>>>
>>>>>>> Is there any workaround to perform atomic updates on blocks or do I
>>>>>>>> have to
>>>>>>>> re-index the parent document and all its children always again if I
>>>>>>>> want to
>>>>>>>> update a field?
>>>>>>>>
>>>>>>>>
>>>>>>> The latter, unfortunately.
>>>>>>>
>>>>>>>
>>>>>> Is there any plan to change this behavior in near future?
>>>>>>
>>>>>> So, I'm thinking of alternatives without loosing the benefit of block
>>>>>> join.
>>>>>> I try to explain an idea I just thought about:
>>>>>>
>>>>>> Let's say I have a parent document A with a number of fields I want to
>>>>>> update regularly and a number of child documents AC_1 ... AC_n which are
>>>>>> only indexed once and aren't going to change anymore.
>>>>>> So, if I index A and AC_* in a block and I update A, the block is gone.
>>>>>> But if I create an additional document AF which only contains something
>>>>>> like an foreign key to A and indexing AF + AC_* as a block (not A + AC_*
>>>>>> anymore), could I perform a {!parent ... } query on AF + AC_* and make
>>>>>> an
>>>>>> join from the results to get A?
>>>>>> Does this makes any sense and is it even possible? ;-)
>>>>>> And if it's possible, how can I do it?
>>>>>>
>>>>>> Thanks,
>>>>>> - Moritz
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>>
>> <http://www.griddynamics.com>
>> <mkhlud...@griddynamics.com>
>
--
Walter Underwood
wun...@wunderwood.org
