Hello, I've some classes with a custom key which I believe satisfy datanucleus-JDO requirements; the key class is as follows: public final class Key implements Serializable { static final long

thank you Andy, using objectIdClass metadata on super classes solved the problem. I'm not sure if inheritance is not involved at all; performing some minor changes to the Key class (removing the

Hi, Take a step backwards. How do you think DataNucleus knows how to persist a field of type `Key`? It doesn't, unless you tell it. You don't define that as an "objectIdClass" for that persistable

me and my team are working on an upgrade of our company's system which as getting kind of forgotten and was running old versions of everything it uses; so developing newer features was becoming a pain

Hello, I'm having a trouble when performing any kind of queries into collections mapped to classes with inheritance. I'm using datanucleus JDO with MongoDB. The key class I'm are using is like

I have added a pull request - i created some two extra local booleans to help track the history because the message is constructed well after a null className is returned. These two booleans could

Yes, make whatever error you see as explicit as possible to whatever situation you have. Since i've not had these things then the message was likely un-specific.

Andy, Thank you for investigating so quickly. And thanks for all your work on Datanucleus. Regards, Chris Mosher

Thx for the report. See https://github.com/datanucleus/datanucleus-api-jdo/issues/68 Seems like when this CDI handling code was copied across from the JPA plugin it wasn't copied exactly, so was

I'm trying to use the Ant task to enhance a class having a field with a custom converter attached, and I'm getting the following class-cast exception. Any ideas what might be causing it, or how to

I found the cause eventually! This part of the error is possibly misleading: It seems to suggest that you need to use a discriminator (which we already are) so that could lead the developer to check

We've noticed a problem where, during object retrieval of an object with a class that is 2 levels derived from an abstract base class, DN displays the message: This was unexpected because: A

I have attached a very simple, two class, test case which reproduces the issue of having no attributes in the base class. A simple one class scenario with no attributes in the base class also

Ah, Doh! I was looking at the wrong parameter. I had assumed it was the Date parameter causing the trouble but it was another seemingly innocent parameter we had been passing into the query - not

The best way to not get a message about passing in a transient persistable object is not to pass in a transient persistable object. Doing what you say above about passing a Date (which is not a

UPDATE: Turns out this was a problem with another parameter, not the date parameter, which was in fact a transient persistable class. I had left this other parameter out of the example, assuming the

This issue is independent of previous interface issues that we recently discussed. In this scenario the base class implements Serializable but I removed that "implements" relationship as a test and

The StateManager and enhancement contract are not the place to change anything. You need to prevent calling dnProvideFields with crap. i.e checkForSchemaUpdatesForFieldsOfObject (i.e where you have

Passing an empty fieldNumbers native array does prevent the dnProvideFields method from throwing an IllegalArgumentException I can raise a pull request for a fix like this if you think it's

I found the code that's adding the dnProvideFields methods during BCE: org.datanucleus.enhancer.methods.ProvideFields.java The execute method is doing the comparison with null here: public