Erick,
thanks for the insight.
FWIW and to add to the context of this discussion,
if we do decide to add the previously mentioned content as a multivalued
field, we would likely use a DIH hooked to our database schema (this is
currently how we add ALL content to our core) and within the DIH, us
The only thing "special" about a multiValued field is that it can have
non-consecutive positions due to the incrementGap. So, if you set the
incrementGap=1, adding 10,000,000 words in one go is the same as adding 1
word at a time 10,000,000 times to a mutliValued field.
I think the only practical
On 5 November 2012 22:26, geeky2 wrote:
> Gora,
>
> currently our core does use mult-valued fields. however the exsiting
> multi-valued fields in the schema are will only result in 3 - 10 values.
>
> we are thinking of using the text blob approach primarily because of the
> large number of possib
Gora,
currently our core does use mult-valued fields. however the exsiting
multi-valued fields in the schema are will only result in 3 - 10 values.
we are thinking of using the text blob approach primarily because of the
large number of possible values in this field.
if we were to use a multi
On 3 November 2012 00:45, geeky2 wrote:
[...]
>
> we are thinking of doing this to represent a 1:M relationship with the
> "Many" being represented as a string in the schema (probably comprised
> either of xml or json objects).
>
> we are looking at the classic part : model scenario, where the cl
