I'm trying to map an entity field that is a set of Java Class objects to a comma-delimited string of the simple class names in the database. The implementation essentially follows the solution proposed by this answer on Stackoverflow: https://stackoverflow.com/a/34061723.

Field definition in my entity:


JPA converter methods - `types` is a Map of (simple class name String, Class) pairs that are allowed:


This works nicely except when creating the JPA meta model for the entity using Hibernate's meta model generator, version 5.2.12 (pretty recent :-). Due to the fact that the unconverted field's type is `Set`, the corresponding constant in the metamodel is typed to `SetAttribute<MyEntity, Class> types`. This, in turn, leads to the following exception when the container deploys the application:

To me, this appears to be a kind of corner case, if not a gap in the design of the JPA specification. What would be the correct behavior here? Should the meta model generator consider the target type of an AttributeConverter (which is String in this case). I tried to annotate the field as @Basic but that didn't have an effect.

We have added an example for a comma-delimited String Type in our User Guide.

Unlike that StackOverflow question, we are using a Hibernate custom Type which is way superior to JPA AttributeConverter.

Nice. Still, why do we invest so much time and efforts in a thing called JPA in the first place, if every second answer I get when using something out of the JPA standard is like "hey, forget about JPA and use our (proprietary) stuff". To a large degree, we are using JPA because we want to remain portable. What precisely makes a Hibernate custom type way superior to a JPA AttributeConverter? Second, can we stick to the question, please. What would be the correct behavior for the JPA meta model generator if it sees a field that seems to be a collection field but which is actually not because of an additional AttributeConverter? What about the exception thrown at runtime?

It's the same with SQL Standard, isn't it?

Sure, that's the case for pretty much every standard for which there are different implementations. But that does not justify suggesting its a bad/naive/unrealisitic idea if someone wants to stick with the standard; in particular, if there is no need to use non-standard features. Which brings us back to the question what precisely makes a Hibernate custom type way superior to a JPA AttributeConverter?

The best way to answer your question is to ask you to try to map a Jackson JsonNode with Attributeconverter or a PostgreSQL ARRAY if you want.

Since the Attributeconverter does not give you access to the underlying JDBC PreparedStatement or ResultSet, you'll see that it's not very easy to achieve that goal.