@IdMapping for custom id class? Plus: equals and hashCode problem?

[famod]

Hi,

we have custom, strongly typed/named id wrappers that are registered in Hibernate via org.hibernate.boot.model.TypeContributor.
All those custom id classes, e.g. SomeEntityId are wrapping a single UUID. So far so good, everything worked until now.

We just started using entity views and we are getting this error:

The resolved possible types [foo.SomeEntityId] are not assignable to the given expression type 'java.lang.Long' of the mapping expression declared by the attribute id[foo.SomeEntityCsvView.getId]!

but SomeEntityCsvView.id has the same type as SomeEntity.id, which is SomeEntityId, no Long involved at all!
SomeEntityCsvView.id is annotated with @IdMapping.

Furthermore (and strangely), for some other entities that are referenced from SomeEntity (e.g. CountryCatalogValue via SomeEntity.country), we are also getting:

The use of the JPA managed type 'foo.CountryCatalogValue' in entity views is problematic because two instances with different state are equal. Equals/hashCode should be based on the identifier for entities and the full state for embeddables.

If we add equals and hashCode to it, all errors disappear but then again, the base class of all of our entities already provides equals and hashCode for the respective id.
This BaseEntity.id has a type parameter, e.g. for SomeEntity extends BaseEntity<SomeEntityId>. Maybe this is part of the problem?

I debugged com.blazebit.persistence.view.impl.metamodel.ViewMetamodelImpl.createValue(ManagedType<?>, Object, Map<Class<?>, Object>, boolean) but since root is always true for this kind of check, it never really looks for the actual id, which is also confusing...

[famod]

Besides, this reads as if equals/hashCode covering just the respective id should be enough (since no embeddable is involved here):

Equals/hashCode should be based on the identifier for entities and the full state for embeddables.

but it enforces all fields to be included regardless.

[beikov]

Hi,

can you share some sample code? Usually, I would recommend you to use embedded ids instead of UserType or custom BasicType, as that is supported best, but I am willing to look into supporting this also if you provide some samples/reproducers.

but SomeEntityCsvView.id has the same type as SomeEntity.id, which is SomeEntityId, no Long involved at all!

I assume this might have to do with the use of UserType.

If we add equals and hashCode to it, all errors disappear but then again, the base class of all of our entities already provides equals and hashCode for the respective id.

The thing is, any non-basic or non-entity-view type usage for an attribute within an entity view can lead to problems if the equals/hashCode of that type is not proper.

Besides, this reads as if equals/hashCode covering just the respective id should be enough (since no embeddable is involved here):

That's true in general, but I really need to see a sample to better understand what is going on :)

[famod]

I will try to put something together. Please just note beforehand that we use BasicType (with a few inheritance levels in between) which we then register via org.hibernate.boot.model.TypeContributions.contributeType(BasicType)).

[mickroll]

I debugged a bit (i am a coworker of @famod). Some validation is done during blazebit bootup, which finally leads to the error message above. I think this is the section causing the error:
https://github.com/Blazebit/blaze-persistence/blob/master/entity-view/impl/src/main/java/com/blazebit/persistence/view/impl/metamodel/ViewMetamodelImpl.java#L149-L151

                        Object instance1 = declaredConstructor.newInstance();
                        Object instance2 = declaredConstructor.newInstance();
                        Object instance3 = declaredConstructor.newInstance();

[...]

                                if (instance1.equals(instance3)) {
                                    context.addError("The use of the JPA managed type '" + javaType.getName() + "' in entity views is problematic because two instances with different state are equal. " + infoText);
                                }

Now, our constructor does nothing in respect of setting ids. We do this by lombok builders like:

@SuperBuilder(setterPrefix = "set")
@EqualsAndHashCode
public class BaseEntity<ID> {
    @Id
    @NotNull
    @Column(name = "id", updatable = false, nullable = false, columnDefinition = "CHAR(36)")
    @ToString.Include
    private ID id;
}
@SuperBuilder(setterPrefix = "set")
public class ExampleEntity extends BaseEntity<ExampleId> {
    public static ExampleEntityBuilder<?, ?> builder() {
        return new ExampleEntityBuilderImpl().setId(new ExampleId(UUID.randomUUID()));
    }
}

So whatever hibernate-known id generation code you call, it will not supply a valid entity with an id. In fact, the debugger showed that both entity instances have null ids.

Is there a way to disable this particular automatic sanity-check (besides com.blazebit.persistence.view.managed_type_validation_disabled). Or to supply it with valid entity instances?

[famod]

Can you elaborate what the problem there is? The only difference AFAICT is that you need to annotate the PK classes and get rid of the custom user/basic types.

Right now our id classes are free of jpa annotations. If they were embeddables they wouldn't.

The nice thing about the TypeContributor approach is that you don't have any direct dependency on hibernate or jpa (in the id classes).

We really consider those id classes to be a central "domain element", not just a "db thing".

I can work on a release this weekend with an update on the config properties available for Quarkus. I'll also checkout if I can make it possible to provide some customizations like type test values.

Cool, thanks! Please let us know how to support.

[beikov]

Right now our id classes are free of jpa annotations. If they were embeddables they wouldn't.
The nice thing about the TypeContributor approach is that you don't have any direct dependency on hibernate or jpa (in the id classes).
We really consider those id classes to be a central "domain element", not just a "db thing".

I get that, but the annotations are really just annotations. You can declare the JPA API as a provided or compileOnly dependency and any JVM will happily load these classes even if the types for the annotations aren't available at runtime. Of course you can do whatever you like, just keep in mind that this is something non-standard and will thus more likely cause issues here and there.

For completeness, you could also define the embeddable mappings in orm.xml files which are JPA standard as well ;)

Cool, thanks! Please let us know how to support.

I will

[famod]

I just remembered another reason that (really) blocks us from using @EmbeddedId:
We use (and very much like!) quarkus-spring-data-jpa repositories, but sadly those don't support @EmbeddedId yet: quarkusio/quarkus#10870

[beikov]

Hmm, but now it does support it? :)

[famod]

Yeah, I fixed it in 2.5.0.Final. We might switch over to @EmbeddedId at some point.

[famod]

@beikov WDYT about this short-term remedy?

public class MyEntityViewConfigurationProvider extends EntityViewConfigurationProviderImpl {
    @Override
    public EntityViewConfiguration createConfiguration() {
        final var cfg = super.createConfiguration();
        cfg.setProperty(ConfigurationProperties.MANAGED_TYPE_VALIDATION_DISABLED, "true");
        return cfg;
    }
}

Plus service loader file.

Seems to work in a QuarkusTest (have yet to check the other setups).

[beikov]

If that works reliably for you, that's great. I just have a gut feeling that this is dependent on the classpath order: https://github.com/Blazebit/blaze-persistence/blob/master/entity-view/api/src/main/java/com/blazebit/persistence/view/EntityViews.java

[famod]

It actually works for all setups (QuarkusTest, Quarkus dev mode, Quarkus JVM mode in docker). 🎉
It's still just a (temporary) workaround we'd like to get rid of at some point.

[beikov]

FYI #1390

[beikov]

And here is the PR that fixes this. I'll close this discussion then :)
#1391

[famod]

Disabling validation via Quarkus config property now works as expected, thanks!

It was just a bit surprising that our own provider (the workaround posted above) stopped working with 1.6.4. But it was only a temporary solution anyway.