[hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4

Hardy Ferentschik hardy at hibernate.org
Thu Apr 3 14:18:45 EDT 2014


On 3 Jan 2014, at 15:28, Sanne Grinovero <sanne at hibernate.org> wrote:

>> I think we dropped the ball on this one. I basically had a look at Guillaume’s pull request.
>> His analysis was correct and his proposed patch brings back the old pre 4.4 behaviour
>> with minimal changes.
> 
> Ok that sounds good, I couldn't look at the PR yet.. should I not trust you ? :)

You definitely, should ;-) I just felt that we kind of left the discussion open ended.

>> There is still the question of the indented use cases of @ContainedIn. As discussed in this thread
>> afaik the indent was as a sole counterpart to @IndexedEmbedded. The implementation (probably
>> as a side effect) made it also work when @IndexedEmbedded was not used. This was changed with
>> the metamodel refactoring where contained in was indeed treated as counterpart of indexed embedded.
>> 
>> I think we should go ahead and apply Guillaume’s pull request for 4.4 and 4.5, basically reinstating
>> old 4.x behaviour, side effect or not.
> 
> +1

Ok then

>> The next question is then what to do in Search 5. I think we can just carry forward the change/patch.
> 
> Yes let's keep them in sync for now
> 
>> I don’t think that @ContainedIn needs another attribute or that we should introduce a whole new annotation.
>> @ContainedIn seems quite natural provided we documented it intend and behaviour. Basically all what @ContainedIn
>> is saying, is that here we have a reference to another entity which needs reindexing as well when the current
>> entity gets reindexed. Whether the inclusions happens via @IndexEmbedded or via a custom bridge is irrelevant.
>> 
>> Thoughts?
> 
> I agree with you, but in insight if this new "meaning" would have been
> explicit on this annotation from the beginning of time, maybe it would
> have had a different name?

Maybe. But what? @ContainedIn kind of fits.

> I don't think the name is appropriate for this more extended meaning;
> probably not a big problem but we can decide on that after it's fixed.

Sure.

> We don't have dates defined, but we can certainly release these when
> there are enough good reasons to: for example if Guillaume needs it.

ok


More information about the hibernate-dev mailing list