Bag versus List

[sebersole]

Historically Hibernate interpreted a List attribute with out any explicit "index details" (@OrderColumn, @ListIndexBase, ...) using bag-semantics. JPA however requires this to be interpreted using list-semantics with default index details. To account for this initially we added JpaCompliance#isJpaListComplianceEnabled.

For 6.0 I propose we change this to:

1. For all List typed attributes, we interpret that as list-semantics
2. For all Collection (non-List) typed attributes, we interpret that as bag-semantics

This has a wide impact. Heck, I made this change by accident working on @CollectionType support and quite a few of our tests fail. So we do need to think through migration. (1) and (2) above would be the default behavior with the following configuration points:

1. Add @Bag annotation to allow marking a List as a bag.
2. Add @CollectionSemantic annotation along the lines of @CollectionType#semantics - this is beyond just the List/Bag discussion, but has an impact here
3. (maybe) change the default for JpaCompliance#isJpaListComplianceEnabled to true. If users explicitly set that to false, we would fallback to the current interpretation. It would no longer strictly be a JPA-compliance choice, but since that infrastructure exists already...

[sebersole]

For the historical record, I was able to isolate this choice through org.hibernate.boot.internal.MetadataBuilderImpl.MappingDefaultsImpl#implicitListClassification. See where this is initialized from the hibernate.mapping.default_list_semantics setting.

Changing the default, if/when we decide to, is simply a matter of changing that one piece of code.

[beikov]

+1 for changing the default. I'm a bit undecided about letting the user specify the "semantics". IMO the only sensible configuration a user can/should do is telling us that something is a "bag" when the declared type is more concrete and would suggest SET/LIST.

Or do you think it will be more common in the future to use stuff like @CollectionSemantics(SET) Collection<..> c;? I don't think this is very useful and AFAIU this is a new feature, right?

[sebersole]

We'll maybe they want to use id-bag by default. And that is not particularly easy to support here.

This only affects attributes defined as List, so Set would not be appropriate.

And in general, I think this notion of using a Java class as a 1-1 correlation to a classification is just not right. The classification is unambiguous unlike some of the Java types.

[beikov]

We'll maybe they want to use id-bag by default.

I don't know much about id-bag, but AFAIU that requires that the user annotates @CollectionId, correct? I'm just trying to understand if switching from LIST to BAG is really the only use case for explicitly specifying the semantics.

[sebersole]

The entire point of the exercise here is how to classify List references when it does not specify certain annotations.

Generally, an id-bag is more performant than a bag.

You just made the argument on another discussion that you don't want to apply "arbitrary restrictions" to features. Well... ;)

[beikov]

So far, I'm still trying to gather use cases and understand how these things could be combined, because to me, it seems that the only case where it is useful for the user to specify the semantics explicitly is for choosing a bag vs. list, although I acknowledge that if the declared type is e.g. Collection, in theory the user could also request SET etc.

[sebersole]

the only case where it is useful for the user to specify the semantics explicitly is for choosing a bag vs. list,

My guess is that for most users this determination is the same across their application, in terms of how they want that interpreted. In other words, I think generally that a user is not going to want that interpreted as LIST in some cases, but BAG in others within their apps. So for that case. I actually think the setting is more useful.

although I acknowledge that if the declared type is e.g. Collection, in theory the user could also request SET etc.

👍 And in general, exposing the classification is just more precise. Plus, in my opinion, its much more clear for users rather than know which magic Collection sub-type to use.

[sebersole]

this is a new feature, right

I mean this is all a new feature. In 5.x you cannot configure how Hibernate should handle this

[beikov]

We decided to revert back to BAG by default but the setting is still there so that users can switch to LIST by default.