I found that setting the parameter to an array of the primitive int or long data type causes the error. I have the error condition primed in my test project at https://github.com/bkalbfus/test-jdo/blob/33f2dd94cf4051258de2d05e2eb52b35d30f8aa0/src/test/java/org/datanucleus/test/ArrayParamTest.java#L62
java.lang.UnsupportedOperationException: Dont currently support operator - in JDOQL conversion
at org.datanucleus.api.jdo.query.AbstractJDOQLTypedQuery.getJDOQLForExpression(AbstractJDOQLTypedQuery.java:519)
Please dont use SQL equivalents, this is JDOQL which has its own (string) syntax using Java syntax; the sooner you adapt to that the better - quoting the string JDOQL form would be a way better way to proceed. As already said, you can use "contains", and so if you want to negate that you call "not()" on the contains expression. Works for me, and in the same way I can create a parameter of type List with Integer elements and that works for me too. If it doesn't for you then you need to debug your usage, and get the DN code.
Using the JDOQLTypedQuery, I appended
.neg() to the contains filter and got the error I quoted above. Test project is updated, please see here
I assume that calling
.neg on a BooleanExpression would be equivalent to wrapping the JDOQL boolean expression in not()
Can someone answer me this? Thanks! https://stackoverflow.com/questions/54737719/datanucleus-jdo-instancelifecyclelistener-for-maketransient-or-load-by-query
If i clear the "default" group, the postLoad listener is not executed...
i'm totally puzzled...
There is something puzzling me, and i cannot find it on the DN docs (even 5.x): Can i programmatically manipulate the "default" fetchgroup (PMF and/or PM wise) so that o can ADD / REMOVE members ? Or is the "default" fetchgroup bounded to the metadata definition?
Andy, i just want to avoid the default fetch group from interfering in the fetchplan i define programmatically... so, i remove it from the fetchgroups of the PM or i change it! There are some operations that i want the default fetch to kick in (so, it is), but others that i don't want the default fetchgroup to interfere!
I will try to test my code with v4 or 5 of DN (i'm having problems because the JDO api is not found... the usual problems under OSGI)
All jars are in the classpath together with JDO javax. No differences here from my production env with DN 2.1
the docs http://www.datanucleus.org:15080/products/accessplatform_4_2/ say JRE required : 1.7 or above
pretty much lost here
Feb 23, 2019 3:57:29 AM org.datanucleus.plugin.NonManagedPluginRegistry getManifestURL
WARNING: Could not find MANIFEST.MF file for plugin file "bundleresource://63.fwk29199470/plugin.xml" so ignoring it
Feb 23, 2019 3:57:29 AM org.datanucleus.plugin.NonManagedPluginRegistry getManifestURL
WARNING: Could not find MANIFEST.MF file for plugin file "bundleresource://63.fwk29199470/plugin.xml" so ignoring it
Feb 23, 2019 3:57:29 AM org.datanucleus.api.ApiAdapterFactory getApiAdapter
SEVERE: Error : Could not find API definition for name "JDO". Perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?
WARNING: Could not find MANIFEST.MF file for plugin file "bundleresource://63.fwk29199470/plugin.xml" so ignoring it
Feb 23, 2019 3:57:29 AM org.datanucleus.plugin.NonManagedPluginRegistry getManifestURL
WARNING: Could not find MANIFEST.MF file for plugin file "bundleresource://63.fwk29199470/plugin.xml" so ignoring it
Feb 23, 2019 3:57:29 AM org.datanucleus.api.ApiAdapterFactory getApiAdapter
SEVERE: Error : Could not find API definition for name "JDO". Perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?
If "all jars are in the classpath" then you can easily provide a testcase as per http://www.datanucleus.org/documentation/problem_reporting.html#jdo
DN 4.x is not supported as already said; only DN 5.1 and 5.2 are supported.
Also
org/datanucleus/store/types/java8/wrappers/ArrayList only exists in datanucleus-java8.jar in the 4.x timeline, so why are you including that in your classpath if you say you are using Java 7???!!! https://github.com/datanucleus/datanucleus-java8/tree/master/src/main/java/org/datanucleus/store/types/java8/wrappers
Removed datanucleus-java8-4.2.0-release from dependencies and i can run the enhancer now... still, running the app throws the "org.datanucleus.exceptions.NucleusUserException: Error : Could not find API definition for name "JDO". Perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?". The fight goes on...
Tried everything i could think of... even looked at the 5.x docs about ECLIPSE OSGI runtime to see if something has changed from 2.x / 3.x to 4.x / 5.x, but i can't see any changes. I still have to install all the DN dependencies as Eclipse Plugins, and pass the "org.datanucleus.api.jdo.JDOPersistenceManagerFactory" CLASS LOADER to the getPersistenceManagerFactory(props, pmfClassLoader)
so, nothing to change here... still, JDO API is not found. Can't even try DN 4 under my test platform.
@andyjefferson, the method getObjectById is considered a LOAD from the database, right? It should trigger the postLoad method of the LoadLifecycleListener interface, right? The docs only say "Invoked whenever a persistent instance is loaded from the data store", and i'm confused, because it does not trigger anything...
getObjectById does NOT necessarily mean ANY round trip to the database; why not actually look at the log?. A load is when fields are needed. Any postLoad is indeed called when the fetch plan is loaded, as per the JDO spec. No testcase demonstrates anything to the contrary
Well, i did a test case with DN 2.1, and i found the reason why i the behavior changed in my app: because the Queries would not trigger the postLoad without the DEFAULT FETCHgroup being in the fetchplan, i changed the whole logic, and defined all the classes with ONLY THE KEY field being in the DEFAULT fetchgroup. After that, i just keep the DEFAULT fetch group (aka, the KEY field!) and add other groups in runtime to achieve the desired effect on queries... PROBLEM!!!!! When i do a simple getObjectById of those objects now, they DON'T trigger the postLoad!!! I need to define another FIELD apart from the KEY one to achieve that!... Andy... I advise DN or JDO to revise the way this works or to update the DOCS with these unknown scenarios so that the users can take a valid approach in the implementation... now i have to think of a new approach...
Final time : if you have some persistence code that creates a problem (with or without capitals), then just demonstrate it with a testcase and then precise details of what you mean are defined. Given your past history of never providing a testcase I won't hold my breath for that. Apache JDO is where you raise problems with capabilities of the JDO spec. Bye
I’ve run into a blocking issue when attempting to upgrade from 5.1.9 to 5.2.0 and have narrowed it down to a change that was made between 5.1.9 and 5.1.10. So upgrading from 5.1.9 to 5.1.10 also does not work. Specifically I use http://www.datanucleus.org/products/accessplatform/jdo/mapping.html#valuegen_uuid and it appears that it doesn’t properly work with this change datanucleus/datanucleus-rdbms@7c75854 - at least that’s what appears to be happening - debugging DN can be challenging when you’re not familiar with the inner-workings.
All along my UUID classes have used the following format:
@Persistent(customValueStrategy = "uuid")
@Unique(name = "TEAM_UUID_IDX")
@Column(name = "UUID", jdbcType = "VARCHAR", length = 36, allowsNull = "false")
@NotNull
private UUID uuid;However, I have also tried the following with the same result
@Persistent(customValueStrategy = "uuid-object")
private UUID uuid;A NPE is thrown in both cases.
java.lang.NullPointerException
at org.datanucleus.store.rdbms.mapping.java.UUIDMapping.setObject(UUIDMapping.java:141)
at org.datanucleus.store.rdbms.sql.SQLStatementHelper.applyParametersToStatement(SQLStatementHelper.java:310)
at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:623)
at org.datanucleus.store.query.Query.executeQuery(Query.java:1967)
at org.datanucleus.store.query.Query.executeWithArray(Query.java:1856)
at org.datanucleus.api.jdo.JDOQuery.executeInternal(JDOQuery.java:433)
at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:276)
at alpine.persistence.AbstractAlpineQueryManager.getObjectByUuid(AbstractAlpineQueryManager.java:518)Am I doing something wrong? Are there any working unit tests for this? I could only spot a single unit test in the rdbms module, so i assume if tests exist they are in another module. I need a 36 character UUID object for these fields and currently haven’t been able to achieve that with 5.1.10 and higher. Any pointers much appreciated.
The normal thing to do with an NPE is work out WHAT is null, and then you can understand why, what situation (of yours) is not catered for, and what fix to contribute. That change is amply documented (IMHO) in the issue tracker, and yes I have a test that it fixes. Clearly I don't have tests for your situations, but then that is why people have been advised to contribute to this project since 2003.
Well, seeing what’s null is easy. https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/mapping/java/UUIDMapping.java#L141 getColumn() is assumed to be not null, but in 5.1.10 and higher it is. I have no idea what it would be null, but will try to dig in and compare to 5.1.9.