JDOQL would be something like Left as an exercise to write that using JDOQLTyped syntax if that is what you're using. No idea what you mean by "implementation for Hub"; they are your classes so you

What would be the Datanucleus/JDO implementation to this: Suppose I have a POJO, `Hub` which represents a place/location: ```java class Hub { List<Schedule> schedules; } ``` And a `Schedule`

Hello Andy, Please find below my response, You post some SQL but don't say how that was executed ... an SQL query? - Yes, it executes as a SQL query. It is a JDOQL query, we create a query object

I'm trying ... -- Stephane

That message says "with a way of reproducing it".

A workaround or solution is to refresh the object before delete. (I don't know enough the spec to qualify as workaround or solution) -- Stephane

Hi, Since I added optimistic locking, with a numeric version attribute, the deletion doesn't work. ERROR DataNucleus.Persistence - Object with id "1" in table I18N_MESSAGE has no version set on the

You post some SQL but don't say how that was executed ... an SQL query? If that SQL is "generated" from JDOQL/JPQL then visibility of the origin of it (aka JDOQL/JPQL and the classes) is sort of

Hello, As part of migration from 2.x to 5.x, we are facing a error because the select statement is having ambiguous column name. Same code was working with previous version, looks like we have to

Thanks for your reply Andy. Right, its hard to answer with this less supporting info, I thought if there is something obvious around it that can be changed. I am checking the stacktrace and would get

Provide BASIS for the error message, such as code, and log entries. That way there is a basis to attempt to answer something that currently has no context. You could, of course, just get the code and

Hello, I am migrating from 2.x to 5.x and getting below exception during runtime, please advice how to fix this issue. datanucleus.query.resultSizeMethod of "COUNT" is only valid for use with JDOQL or

Refactor what code? Why are you making explicit reference to "PersistenceCapable" in the first place? It has never been advisable to use an internal interface (which is what it is when part of the JDO

Hello, I am migrating from 2.x to 5.x and all my old code is around javax.jdo.spi.PersistenceCapable(types casting from object type etc). But now when I enhanced my classes using latest version, I can

Changing code back to some ancient version on a whim is not an option in a responsible software project. Facts must be provided first, as stated above, that is the prerequisite.

Thanks for your reply, I was moved to another task so couldn't look around this. You mean, you have a field MYFIELD (with col name MYCOL) of some type that is mapped to BLOB? and if you don't bother

Thank you Andy for pointing me to the right point in the documentation.The problem arose because I forgot setting the persistence property "datanucleus.query.sql.allowAll" to true. This caused my

JDO (and JPA) don't do automatic changes to schema. They do CREATE or DELETE only. Metadata (for schema) is only ever used on a CREATE, and since you already have tables it is up to you to have the

Hello all, I have defined a java class using the default attributes: @PersistenceCapable(detachable = "true") public class PropertyTemplate { ... private String description; ... } And stared

You mean, you have a field MYFIELD (with col name MYCOL) of some type that is mapped to BLOB? and if you don't bother specifying the length of the field in metadata then it picks MYCOL