It's an interesting idea but I am not sure it works in that many practical cases. It's definitely worth exploring though.
Here are a few comments: - does not work for embedded collections - => does not work in a bidirectional @ManyToOne ot @*ToMany environment (quite common) - work in a unidirectional env where the associated entity has no back dependency - will need to store _hibernate_class for the associated entities - mental note to stop talking with you, it generates weird ideas I've noticed that you're quite concerned about index size generally, do you think size is a major drawback? On 15 mars 2011, at 19:00, Sanne Grinovero wrote: > 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
