AttributeConverter based attributes are not marked for update when their state is modified
Description
is followed up by
Activity
Steve Ebersole October 2, 2015 at 2:43 PM
Because you mentioned it above as being related. It's not at all related. Try to understand that Jira is also a historical record. People will come here later and see all these discussions and I do not want them incorrectly thinking that this and HHH-8354 are in any way related.
Yes, implementing Serializable would have been a work around, but not a solution. It would have worked on an internal assumption.
JohnA September 25, 2015 at 3:43 AM
Hi Steve, not sure why you think I associated it with those tickets. As mentioned, searching around for information about attribute converters, and dirty checking was turning up fruitless so searching for different terms ended up leading me to those JIRA tickets. The fact that bytecode enhancement at the build level makes it work makes me think it's somewhat related. In addition, the fact that JavaTypeDescriptorRegistry has the comment // MutableMutabilityPlan would be the "safest" option, but we do not necessarily know how to deepCopy etc...
It's probably also worth noting that implementing Serializable would have fixed this, it seems.
Steve Ebersole September 24, 2015 at 3:18 PM
Not sure why/how you came to associate this with HHH-8354. HHH-8354 is something completely different; it incorporates dirty tracking into a bytecode enhanced entity directly. You are not using bytecode enhancement here. Your report is in relation to an AttributeConverter.
Thanks for the analysis. I think the solution is not so much in the dirty checking; I think more that we need to understand that this is a mutable object (its internal state is mutable) which would mean a different dehydrated/disassembled form. But either way, I will take a look.
Vlad Mihalcea September 21, 2015 at 11:11 AM
Indeed. The bytecode enhancing was not really working in 4.x.x and all fixed came into 5.0.0.
I think this issue should be resolved by fixing the default dirty checking mechanism.
JohnA September 21, 2015 at 10:38 AM
Yes, and the other issue is that the solution I found only works with Hibernate 5. When using the plugin from Hibernate 4.3, I get errors that any child object cannot be found in the class cache. The plugin never generates an enhanced version of the entity.
I've created a sample project that demonstrates the issue
https://github.com/johnament/hibernate-attr-converter
You can override the hibernate version to 4.3.11, 5.0.1 the issue is present in both.
If you run JPA1Test#shouldInsertNewSimpleEntityAndUpdateWhenSettingName the console output includes
Hibernate: drop table simple if exists
Hibernate: create table simple (id bigint not null, name varchar(255), primary key (id))
Hibernate: select simpleenti0_.id as id1_0_0_, simpleenti0_.name as name2_0_0_ from simple simpleenti0_ where simpleenti0_.id=?
Hibernate: insert into simple (name, id) values (?, ?)
Hibernate: update simple set name=? where id=?
Which looks right, but it requires you to explicitly call setName on the entity. This is prevalent in #shouldInsertNewSimpleEntityButDoesntUpdateWHenModName, which is the preferred way to modify the entity.
Is there anyway to make this work, other than making hibernate aware of these entities as well?