On 29 April 2014 11:28, Hardy Ferentschik <ha...@hibernate.org> wrote: > > On 29 Jan 2014, at 00:14, Sanne Grinovero <sa...@hibernate.org> wrote: > >> I'd avoid a new configuration element. > > +1 Sure, that would be best. > >> I think we should strive at keeping the index small by default unless >> there is a strong usability penalty, and I don't think this is a big >> one. > > I agree. I don’t think there is a good reason for including the id of the > embedded > entity by default, especially since it leads to potential problems as > described in HSEARCH-1494. > >> Some power users pointed out that there are use cases in which having >> the _id_ field of embedded relations is useful, so we should still >> allow to add it when someone explicitly flags the need for it. > > Sure. My questions was basically about how we allow this type of id inclusion. > >> Now the complexity is I guess to define what it means to "explicitly >> flag the need for it”; > > exactly :-) > >> I think @IndexedEmbedded should not include it >> by default, unless explicitly listed via the _includePaths_ attribute. > > include paths is one use case, but there is also the default @IndexedEmbedded > behaviour > which includes all indexed field (including the id atm). > >> Question: would we still interpret the literal "id" as a keyword >> pointing to whatever getter is the primary key of the embedded object? > > Why still? We don’t do this at the moment afaict. Our examples and tests just > use ‘id’ > all the time.
Right I got confused. I thought for a moment that we would encode the primary identifier as a specific keyword, but there's no reason. Forget what I said :) > >> I'm inclined to seek for a property which has the name as listed in >> _includePaths_, not giving the "id" literal a special treatment in >> this case. > > I am not following you here. What do you mean? Also you seem to just target > the includePath case. Yes I mean we could never include it by default, and allow the "includePath" to be the (only) way to include things. Remember _includePath_ is additive to fields otherwise included via @IndexedEmbedded _depth_, so it fits nicely for this role: for non-indedex embedded elements it's of course nonsesense (as usual) to specify an attribute which is lacking a @Field or similar option, while for indexed types we implicitly apply one on the primary identifier, this just needs to be selectable via _includePath_. > Another thought would be to make this a global configuration option. > Something like > hibernate.search.embeddedindexing.include_id_property. Per default the flag > would be false, but > could be set to true. Obviously this is a quite coarse solution. I wouldn't do that now, but we can certainly leave this option open for future evolution. Cheers, Sanne > > —Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
