[hibernate-dev] About mapping of @IndexedEmbedded and @DocumentId

[Sanne Grinovero]

Well not being this very urgent I'm going to create two JIRAs, on it,
one for the norms, and one for possibly changing the storage of the
optional field.
just wanted to mention it as while debugging I found it surprising behaviour.

*But* your last sentence got me a weird idea.

Nowadays if you have two related entities, both indexed, and one is
@ContainedIn in the other, we'll create two documents. Actually if you
think about it, we create two documents which contain exactly the same
values, just the fieldnames are different.
So what happens is that we're actually duplicating the size of the
index, or even more depending on the depth of the tree of indexed &&
related objects. And we also analyse the same text twice, using the
same analyser.

If we had something like "virtual fields", something for which we
dynamically map the fieldName to an internal different name, we could
re-route indexing and also queries built using the DSL in clever ways,
having them point the correct fields.

The downside is of course that we take away the option to directly
access the Document in FieldBridges and ClassBridges - nasty, but
we'll likely need that anyway as nothing is serializable anymore, so
we already need to provide some proxy object mimicking the Document,
to be used as a value container to being sent to the backend.

Other smaller advantages:
 * We'll be able to intercept what FieldBridges actually write to,
don't remember now but in some cases we where stuck on that (like
detecting duplicates and conflicting fieldnames)
 * some better JOIN implementations can use it, as long as the number
of elements is limited, by creating fieldname_1 fieldname_2, etc.. or
just using the same name but controlling the order in which they're
listed.
 * Updating index - a single document can be split in parts, so that
when an entity is indexed we don't have to reload/rewrite many related
entities. Don't know the details, but remember having read some
limited form of this is possible.

I'm sure we can come up with more, let's see if it's worth the
complexity and other problems. I'd propose it for version 4, a nice
breaking change :)

Cheers,
Sanne




2011/3/15 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 15 mars 2011, at 18:24, Emmanuel Bernard wrote:
>
>>
>> On 15 mars 2011, at 16:43, Sanne Grinovero wrote:
>>
>>> I guess we should prevent the indexing of ids in secondary elements?
>>
>> If the associated element is an entity, it's perfectly valid to index its id and query by it
>>
>> //return all books when the author's id is 2
>> "author.id:2"
>
> So if we find a way to support this use case and yours, let's go.
> BTW I agree we should at least not store the norm.
>
> Maybe something like that:
>
> //default to todays' behavior minus the norm
> @DocumentId(indexWhenEmbedded=@Field(...))
>
>