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 <emman...@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(...)) > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
