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