datanucleus / datanucleus-api-jdo Goto Github PK

So the user can do

@readonly
public class MyClass {...}

to equate to

@extension(vendorName="datanucleus", key="read-only", value="true")
public class MyClass {...}

Could add LocalTimeExpression, LocalDateExpression, LocalDateTimeExpression to accepted expressions and then update datanucleus-jdo-query to add these to the Q classes.

Not yet in the JDO spec but should follow what the PM does regarding closure

executeUnique should return an object of candidate/result type but returns a List currently.

Refer to datanucleus/datanucleus-core#134

Provides a shortcut to the @extension annotation or XML extension usage

@MultiTenant(column="TENANT", columnLength=255)

or

@MultiTenant(disable=true)
to disable it when enabled globally

Feature Request:

Add a check for situations where @column or @element is used on then Many side of a relation (Datatype List) causing only the first ID of Many relation is stored.

@javax.jdo.annotations.PersistenceCapable @javax.jdo.annotations.Inheritance(strategy = InheritanceStrategy.NEW_TABLE) .... public abstract class Step { @Column(name = "toBeFinished", allowsNull = "true") private List<Step> stepsToBeFinished = Lists.newArrayList();

Was generated with a column in the table but only the ID of the first element was stored. Instead I would have expected an error about this situation.

The JDO spec has various rules about the ObjectIdClass, and one of these is that all fields should be present in the PersistenceCapable class. With our "targetClassName" extension this is not present, so we need to avoid this check for that field name

Maps on to the extension "comparator-name".

If we have a persistence unit with non-jta-data-source set but not jta-data-source currently we just put the non-jta-data-source as secondary, and assume the user has defined a primary using the connectionURL/connectionDriverName etc. We should instead use the non-jta-data-source as primary.

See #28

Part of MetaData API, and also input metadata. We already have an extension in internal metadata available for use, just needs setting.

See #49

Refer to core issue 19

The JDO 3.2 spec has a close method but all that it mandates is that it calls closeAll releasing all results. It would make more sense to have it release all resources and connections to other objects (PM, underlying query etc). We need this to be configurable to make it compliant whilst still allowing the option of sensible behaviour

See datanucleus/datanucleus-core#121

See the JPA equivalent

Better to unset everything

If a user specifies @Embedded with no attributes, we should set
embedded="true"
on the member and nothing else. Currently it will add EmbeddedMetaData with no information in it.

See ElementMetadataImpl, KeyMetadataImpl, ValueMetadataImpl, MemberMetadataImpl.

We now have MetaDataManager available on internalMD so possible to do these now.

A simple way of providing a level of auditing of records would be to allow a user to have a field in their entity marked with @CreateTimestamp or @UpdateTimestamp and the datastore column have the timestamp persisted depending on whether being created or updated.

Requires changes to bytecode enhancement contract.

Hi,

I am following recipe described here:

http://www.datanucleus.org/products/datanucleus/jdo/stored_procedures.html

I need to call stored procedure. I used postgresql RDBMS

The code snippet:

        PersistenceManager pm = pmf.getPersistenceManager();

        Transaction tx = pm.currentTransaction();

        try {

            tx.begin();

            Query query = pm.newQuery("STOREDPROC","foo");

            query.execute();

            tx.commit();

        } finally {

            try {

                rollbackIfActive(tx);

            } finally {

                pm.close();

            }

        }

results in stack:

javax.jdo.JDODataStoreException: Error encountered when extracting results for SQL query "foo"
at org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:543) ~[datanucleus-api-jdo-4.1.1.
jar:na]
at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:242) ~[datanucleus-api-jdo-4.1.1.jar:na]
at org.dcache.services.billing.db.impl.datanucleus.DataNucleusBillingInfo.executeStoredProcedure(DataNucleusBillingInfo.java:275) ~[dc
ache-core-2.17.0-SNAPSHOT.jar:2.17.0-SNAPSHOT]
at org.dcache.services.billing.db.impl.datanucleus.DataNucleusBillingInfo.aggregateDaily(DataNucleusBillingInfo.java:263) ~[dcache-cor
e-2.17.0-SNAPSHOT.jar:2.17.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_25]
at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0_25]
at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:65) ~[spring-context-4.2.6.RELEASE.jar:4.2.6.RELEASE]
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54) ~[spring-context-4.2.6.RELEASE.jar:4.2.6.RELEASE]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_25]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_25]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_25]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_25]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_25]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]
Caused by: org.postgresql.util.PSQLException: ERROR: syntax error at or near "CALL"
postgresql log says:

2016-06-01 14:03:59.794 CDTERROR:  syntax error at or near "CALL" at character 1
2016-06-01 14:03:59.794 CDTSTATEMENT:  CALL foo()

postgresql does not support CALL to invoke procedures, it uses select.

I understand that I could do something like

Query query = pm.newQuery("javax.jdo.query.SQL","SELECT foo()");

but then it won't work with Oracle for instance. Help?

Should use createPersistenceManagerFactory(...)

Found in 5.0.1:

The JDOQLTypedQueryImpl.close() routine throws a NullPointerException on every call unless you happen to call getFetchPlan(), as only getFetchPlan() initializes the fetchPlan variable, but the close() routine assumes it's always non-null.

Once fixed, should allow the following auto-close to work properly:

try (JDOQLTypedQuery<SomeClass> tq = manager.newJDOQLTypedQuery(SomeClass.class)) {
    // work            
}

Need an annotation @SoftDelete on a class

JDO (in DataNucleus) has always defaulted to pessimistic transactions (though by default NOT locking objects). This originated in not supporting optimistic transactions back in the early JPOX days. JPA defaults to optimistic, and makes sense to to do the same for JDO.

Still got various tests that show side issues with moving to optimistic as default, so postponing

We currently have toString() methods on all internal metadata classes, outputting JDO XML metadata. These should go in the JDO API plugin.

Some deprecated methods were actually removed in JDO 3.2. Remove them from our implementation

See #23

Since we use the DN-internal single field id PK classes now, this is failing a check at
org.datanucleus.metadata.AbstractClassMetaData.validateObjectIdClass

The simple workaround is to specify DN-specific PK fields, or provide an objectIdClass for the object that makes up the PK.

The stack trace with v4.0.3 is as follows

Class "mydomain.model.CompoundTarget" has been specified with an object-id class mydomain.model.CompoundTarget$Id which has a field source. The field mydomain.model.CompoundTarget$Id.source has type javax.jdo.identity.LongIdentity but should be org.datanucleus.identity.LongId. All non static fields of an objectId class must include the names of the primary key fields in the JDO class, and the types of the corresponding fields must be identical.
org.datanucleus.metadata.InvalidPrimaryKeyException: Class "mydomain.model.CompoundTarget" has been specified with an object-id class mydomain.model.CompoundTarget$Id which has a field source. The field mydomain.model.CompoundTarget$Id.source has type javax.jdo.identity.LongIdentity but should be org.datanucleus.identity.LongId. All non static fields of an objectId class must include the names of the primary key fields in the JDO class, and the types of the corresponding fields must be identical.
at org.datanucleus.api.jdo.JDOAdapter.processPrimaryKeyClass(JDOAdapter.java:551)
at org.datanucleus.api.jdo.JDOAdapter.isValidPrimaryKeyClass(JDOAdapter.java:464)
at org.datanucleus.metadata.AbstractClassMetaData.validateObjectIdClass(AbstractClassMetaData.java:1442)

See #23

See #28

Currently leaves the link, which won't benefit garbage collection