java.util.Datefield. In older versions (we are coming from 4.1) the field is populated with a plain
java.util.Dateobject and in 5.1.2 it is a
org.datanucleus.store.types.wrappers.Dateobject. It looks like the getValue is not used on the wrapper somewhere in the code. Other objects (at least the ones we use) are okay so far. Is this change intended and we have to adapt to it?
@andyjefferson is there any plans to integrate DataNucleus with Micronaut Data (https://github.com/micronaut-projects/micronaut-data) other name Predator. You can read about https://objectcomputing.com/news/2019/07/18/unleashing-predator-precomputed-data-repositories
Micronaut is a new good replacement for de-facto standard in the current Java world Spring Boot. Micronaut is similar to Spring but it completely eliminates reflection, runtime proxies, and dynamic classloading. So you can get significant performance gains, small footprint and startup time.
Especially it is very interested with GraalVM Substrate native images to build efficient native cloud microservices and even FaaS.
Currently they support just JDBC and JPA based on Hibernate. And of course due to the proxy nature of Hibernate they could not get all benefits of AoT on their platform when using JPA.
I believe that is so exited opportunity for DataNucleus which is using compile time code enhancements instead of proxy and reflection API to become the primary JPA solution for Micronaut.
@andyjefferson I decompiled the class with 'javap -c', I could see the getValue and setValue method.
Also the notice the comments for dnGet/Set as well
30: invokevirtual #408 // Method dnGetValue:()Ljava/lang/String;
33: invokevirtual #390 // Method dnSetValue:(Ljava/lang/String;)V
Debugged and noticed the AbstractClassMetaData.class, getManagedMembers () returns 2 FieldMetadata and 1 PropertiesMetaData (corresponds to the field tagged using <property> tag in jdo) for this case.
could there be any difference in using the Field and Properties in jdo mapping with respect to latest version of datanucleus.
obj=entityManager.merge(obj). As the object is persistent and current values are in database I believe merge function should do nothing and give back reference to obj. But instead it goes like this:
at org.datanucleus.state.StateManagerImpl.makePersistent(StateManagerImpl.java:4519) at org.datanucleus.ExecutionContextImpl.persistObjectInternal(ExecutionContextImpl.java:2085) at org.datanucleus.ExecutionContextImpl.persistObjectWork(ExecutionContextImpl.java:1869) at org.datanucleus.ExecutionContextImpl.persistObject(ExecutionContextImpl.java:1724) at org.datanucleus.api.jpa.JPAEntityManager.merge(JPAEntityManager.java:695)and on StateManagerImpl.java:4519 it makes obj.dnStateManager.dirty=true which seems to be wrong as no fields are dirty.