datanucleus / datanucleus-odf Goto Github PK

When we retrieve a List from ODF we retrieve it in the exact same order as persisted. That is, it is stored as a Collection in the owner object. If a user puts some @orderby annotation they may want the list reordering.

This applies to ALL non-RDBMS datastores, so creating some generic code would make sense and reorder them in-memory, maybe using a Comparator.

When we make use of a persistable class in the ODF plugin we currently go direct to "manageClasses", whereas we should simply check for StoreData, and only then go to ODF object to check it.

When it is ever released (3 yrs on from 0.8.7 and still waiting)

Refer to core issue 128 for database creation/deletion

The ODF store doesn't fully support versions when the version is exported into the object.

This occurs against the 5.0.1 platform.

@PersistenceCapable
@Version(strategy = VersionStrategy.VERSION_NUMBER,
    extensions = {@Extension(vendorName = "datanucleus", key = "field-name", value = "version")})
public class Project {

    @Persistent(customValueStrategy = "uuid", primaryKey = "true")
    private String id;

    private String name;

    private long   version;

    /* Standard Getters / Setters skipped */

Attempting to insert a new record causes the insert to succeed but an exception is thrown:

Caused by: java.lang.NullPointerException
    at org.datanucleus.store.odf.ODFPersistenceHandler.insertObject(ODFPersistenceHandler.java:173) ~[datanucleus-odf-5.0.0-release.jar:?]
    at org.datanucleus.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3365) ~[datanucleus-core-5.0.1.jar:?]
    at org.datanucleus.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3341) ~[datanucleus-core-5.0.1.jar:?]
    at org.datanucleus.ExecutionContextImpl.persistObjectInternal(ExecutionContextImpl.java:2082) ~[datanucleus-core-5.0.1.jar:?]
    at org.datanucleus.ExecutionContextImpl.persistObjectWork(ExecutionContextImpl.java:1925) ~[datanucleus-core-5.0.1.jar:?]
    at org.datanucleus.ExecutionContextImpl.persistObject(ExecutionContextImpl.java:1788) ~[datanucleus-core-5.0.1.jar:?]
    at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:713) ~[datanucleus-api-jdo-5.0.1.jar:?]
    at org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:739) ~[datanucleus-api-jdo-5.0.1.jar:?]

Removing the @extension fixes the exception, but then the version field isn't updated with the real version number.

I can't tell if the bug is in the ODF Handler around versions or in the Core around the building of the versionColumn field in CompleteClassTable.

Refer to core issue 19

Refer to datanucleus/datanucleus-core#134

When we execute a query and use FetchFieldManager, we have to use the constructor for an ExecutionContext (i.e ObjectProvider not yet known). This means that we cannot easily wrap any SCO fields in FetchFieldManager. Consequently we need to call

ObjectProvider.replaceAllLoadedSCOFieldsWithWrappers()

just after the FetchFieldManager process.

See datanucleus/datanucleus-core#81