@Andy Thanks for your reply. I am using jdk 8 with parameters source=1.5, target=1.5 as I have some legacy jars and using Datanucleus 5.2. I have read Datanucleus enhancer reads the compiled class and

I've not tried running on Android, but heard some time ago from one of our contributors (IIRC "nlmarco" from Nightlabs/Codewizards) that they had been doing something about using Android (I think it

I have seen rumours of Datanucleus running on Android. I assumed it would because of SQLite support, but this was a mistake. Before I switch to a different persistence method, is there any way that

Using inconsistent JDK for the version of DataNucleus you are using. You don't mention *what* you are using in terms of JDK, and version of DataNucleus. Stick to what the docs say is supported and you

I am doing version upgrade of Datanucleus jars. Now, during compilation, I am getting below stacktrace in DataNucleus.log. (main) ERROR [DataNucleus.Enhancer] - Error thrown enhancing with

The only answer is to debug things (by getting the code and comparing). If you run it with some ancient version then you can look at what SQL is generated with that. And if it is trying (with current

After updating of DataNuleus from version 3.3 to 5.2, I get the following error from the query, which limits the max. fetch depth. This Query works correctly with DataNucleus

The attachment is a Junit test to reproduce the case. I hope you can add it to DN test-suite. here is the field with the converter, where length is 4096 (over 255 to be sure) @Convert(converter =

Post the relevant bits of relevant classes in the POST, no time to download. A length of a column is only used in schema generation. @Size is part of javax.validation (not JPA), which is something

Hi, When I use an attribute converter on an attribute, DN does not load the length validation attribute, keeping its default 255 value. (debug shows the length attribute is 255, probably not

This paragraph from the "Changes in MySQL 8.0.16" page (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-16.html) looks interesting:Although, as we're using InnoDB and not NDB then it appears

Thanks for those details. I'll try to debug this. I assume that ColumnOrderedKey is used regardless of the number of columns in the index. i.e. it is used for single key indexes as well as composite

Sets the relative position of a column that is part of an index. So if you have a composite index formed of two columns, the index behaves differently dependent on the ordering / position of

Has anyone else seen this issue before? Everything has been working fine for all MySQL 5.x versions but after exporting the database as a SQL dump from 5.7 and importing the SQL dump into a new

Presumably the warning is indicating a possible "non optimal performance" SQL query rendered from the JDOQL. If a WHERE clause of discriminator conditions are left out then the range of records the DB

Thanks for giving me the direction to look in, I'll try see if I can remove the use of modules and maybe that will fix it. I did just try something with Maven, I created a parent and child pom,

Compare the "maven --debug clean compile" output between JDK 8 and JDK 13 for a basic case. The real difference between those is "Jigsaw" (java modules) addition to the JDK. I don't use it. Similarly

It seems to be failing when it goes to search for the type annotation classes to compile resources using them? But my experiance with this type of thing is very little so I am extremely lost as

If it fails before generating JDOQLTypedQuery classes (i.e the preCompile step), then where is it failing?? maven --debug tells you way more than we see here. Posting the class is irrelevant if that

After my misguided attempt to get some help on github I'm trying to do it correctly here (: I'm in the midst of setting up a JavaFX project with Datanucleu + JDO + JDOQL. I've got the first two