We are currently trying to migrate from Hibernate 5.6 to 6.5 and as part of this came across that the AbstractEntityTuplizer class has been removed.
In our codebase, we are extending this class and using it for the following purposes -
creating the instance of entity which is defined by Instantiator interface (using methods like instantiate() )
extracting values of a property from the entity which is defined by Getter interface (using methods like buildPropertyGetter(), getIdentifier() etc)
injecting values for a property into the entity which is defined by Setter interface (using methods like buildPropertySetter(), setIdentifier() etc)
I checked your codebase to find any reasoning / alternatives for this class in the commit -
But I didnt find much information related to it.
Also the Instantiator class has been deprecated since version 6.0
I have searched online for any alternatives for these classes but I havent found much information.
The only thing I could find relevant was EntityRepresentationStrategy class. This seems to have methods which are similar to the ones in the Tuplizer class. Also EntityInstantiator class which seems to have similar methods to the Instantiator.
I wanted to know if these are the actual alternatives for the classes I mentioned or if they are meant for a different purpose.
Would love to get more information regarding this and any links to documentation would be of great help.
EntityRepresentationStrategy and EntityInstantiator are indeed similar interfaces, but they are SPIs, not APIs, so they’re not supposed to be overriden by the end-users.
Would you mind expanding on why you would need custom entity instantiators and / or custom getters and setters for properties? At the moment, as far as I know, it’s only possible to plug-in custom instantiators for embeddable types and not for entities.
In our implementation, we have a custom type to represent the entity. (say EntityProxy)
Now each time we interact with Hibernate, we are transforming the results that are provided, into the EntityProxy type and vice versa. This EntityProxy is being instantiated using the custom implementation of the Instantiator interface.
Along with this we have implementations of the org.hibernate.property.access.spi.Getter and org.hibernate.property.access.spi.Setter which extract / inject values of a property of the EntityProxy respectively. i.e. these implementations will directly get / set the property values from / to the EntityProxy by converting the objects to this type.
All of this was being taken care by the Tuplizer class which was extending AbstractEntityTuplizer which has been removed now. Thus its a big issue for us as we were heavily relying on this logic for interacting between Hibernate and our EntityProxy type.
I understand you are instantiating and manipulating custom types, what I was asking is really why do you need this EntityProxy? Can’t you just work with the classes used in your mapping model?
As a note, you could consider using DTOs, but they only work for queries.
why do you need this EntityProxy?
We are using it to model our custom type (which acts as a generic interface to model any kind of entity) and this is how it had been modelled in our legacy system. We were using the Tuplizer mechanism for performing the conversion to and from this type of ours.
Can’t you just work with the classes used in your mapping model?
We have a legacy implementation and so we are still working with hbm.xml files actually. We are not using classes to map our entities.
you could consider using DTOs, but they only work for queries.
Please correct me if I am wrong but DTOs would be similar to the annotated classes used to represent the entity, right? If so, we are not using these classes to model the entities instead we are using hbm xml files to map the entities.
We are hoping for a mechanism similar to the Tuplizer so that it could be a kind of workaround for us.
No, DTOs have nothing to do with annotated classes. They can be simple java beans which contain the data you’re retrieving from the database.
The hbm.xml format has been deprecated for a long time, and will be removed in the coming versions of Hibernate. I strongly suggest considering a migration to either annotated classes or at least the new orm.xml format (see this discussion for tips with using the hbm.xml trasnformer tool to help with migration).
Regarding the orm.xml format, we have previously had a detailed discussion about it in this thread -
Wherein you have mentioned about the transformer tool but since its not completely ready as suggested by you, we have not gone for this right now. Will probably use it when we decide to move to future versions of Hibernate. Till then, since the hbm.xml files still work with hibernate 6, we would like to go ahead with them also keeping in mind the timelines of our release as well.
However that being said, this will still not solve the Tuplizer issue that we are facing. So if you have any workaround for that, it would be much appreciated.
Hi @Kaushik_LV
Have you found a suitable solution to this problem? We are currently encountering the same issue. In our code, we use Tuplizer and hbm.xml files to represent dynamic modeling. However, after upgrading to Hibernate 6.5, we have no idea how to adapt…
Hi @fengjiansheng
Currently I have written a custom Tuplizer which performs a similar task as that of the AbstractEntityTuplizer and it has passed our preliminary tests. I am in the process of running all the tests and checking if it works for all the scenarios.
Since it has been removed from their codebase without any other direct replacements for it, I feel there is no other way other than to implement your own.