UserCollectionType

[sebersole]

We've discussed UserType and CompositeUserType, but have not explicitly discussed CollectionUserType.

I had intended pluggable CollectionSemantics to act as the replacement for CollectionUserType. To that end, it already defines all of that functionality. I do wonder though if we always have convenient access to it for write-paths.

From org.hibernate.mapping.Collection:

	public CollectionType getCollectionType() {
		// todo (6.0) : hook in CollectionSemantics
		if ( typeName == null ) {
			return getDefaultCollectionType();
		}
		else {
			return MappingHelper.customCollection( typeName, typeParameters, role, referencedPropertyName, getMetadata() );
		}
	}

[gavinking]

@sebersole I'm not clear on what you're proposing/asking.

[beikov]

I guess this is about the support for table and array types of databases that we discussed yesterday @sebersole? I unfortunately can not follow though. If you know what you meant here in 2-3 months when we dive into this kind of stuff, it's fine to discuss this later, but maybe you should add some more details about your thoughts :)

[sebersole]

@sebersole I'm not clear on what you're proposing/asking.

Dunno, seems self explanatory. The intention was to use this "forum" as a historical record for why things were done. We will need to bridge this CollectionSemantics and CollectionUserType mismatch. Hence this "discussion" (which is really just a historical footnote).

[sebersole]

We now have multiple ways to influence how a collection is handled:

• @CollectionClassificationType
• @CollectionSemantics (not yet implemented, but on my task list for next week)
• @CollectionType

Pretty happy with all of those, though I do propose we change @CollectionType a bit to no longer allow String type() following the general work we've done to get away from String-based annotation config. What I propose is this:

public @interface CollectionType {
    Class<? extends UserCollectionType> implementation();
    Class<?> semantics() default void.class;
    Parameter[] parameters() default {};
}

This keeps CollectionType#semantics as-is, but honestly I think we should consider just dropping it. I think this is better way to achieve the same:

@CollectionType( implementation = MyCollectionType.class )
@CollectionClassificationType( BAG )
private List theList;

[beikov]

Maybe I'm not seeing it, but why does the user need to specify the collection "semantics"? Isn't that something the UserCollectionType implementation should tell us?

[sebersole]

Maybe I'm not seeing it, but why does the user need to specify the collection "semantics"? Isn't that something the UserCollectionType implementation should tell us?

Well, sure we could change UserCollectionType to expose that. But at the moment it does not. Looking at the "returned class" is not enough, if that is what you are thinking here.

[sebersole]

Pretty happy with all of those

@CollectionType is currently deprecated. Do you propose to undeprecate it?

That would be the assumption if we want to keep supporting UserCollectionType

[beikov]

Well, sure we could change UserCollectionType to expose that.

I would prefer that. Fewer options for the user to configure wrong :)

That would be the assumption if we want to keep supporting UserCollectionType

Sounds good to me. Wasn't this a kind of deprecation that we did to signal EAP customers which we decided to revert?

[sebersole]

I would prefer that. Fewer options for the user to configure wrong :)

CollectionType, for the most part, is unchanged - and maybe even completely unchanged. We really don't have to go around changing each and every little thing "because we can (because its a new release)". We should have good reason. Maybe they use a UserCollectionType that they do not control. I really much prefer we put this on the annotation.

Sounds good to me. Wasn't this a kind of deprecation that we did to signal EAP customers which we decided to revert?

This seems to be the path we are going down in other places as well - undeprecating stuff

[sebersole]

One thing that came up implementing this stuff and writing tests and docs is that atm, supplying a custom PersistentCollection is really very difficult - it requires a lot of understanding of internal concepts, not to mention it is a ton of methods to implement. Even extending AbstractPersistentCollection does not help much. And AbstractPersistentCollection is currently internal.

E.g., for the doc example I was trying to implement unique-List support (cross between List and Set semantics). It is a real pita to do this.

[sebersole]

One option would be to move AbstractPersistentCollection out of internal into api/spi and create base forms for persistent lists, sets etc.

[gavinking]

Might need to clean it up a bit, but it's definitely worth considering.

[sebersole]

Moving much of o.h.collection.internal to o.h.collection.spi, marked as @Incubating which gives us some flexibility to clean these up later