Hi, I faced issues to use the SchemaTool with MySQL 8 failing to upgrade the schema or to recreate it from scratch, with the error "Index/candidate part #0". In a debug session of the SchemaTool, I

And now back.

Currently unavailable due to change of ISP. Use downloadable docs from sourceforge. Hopefully back soon

Use of "fetch-fk-only" simply omits the join to the related table (for performance, as the log shows). When processing the result of the query it will populate the (relation) field with an object of

Now that I think about it there is probably no easy way to change that in DN. From what I saw until now I assume DN has no cache for the FKs. What 'fetch-fk-only' does is to assign a hollow object to

I just wrote you so you know using 'fetch-fk-only' can lead to behavior changes that may not be obvious to the user. But I assume if we use 'extensions' we have to expect changes in behavior. If you

"foreign keys to not existing primary keys" You mean you have zero data integrity? Down to you persisting some data without using JDO and it was rubbish? Nice; good luck with that one. If you have

Hi again There is a behavior change if we use 'fetch-fk-only' that kind of hurts us. We have foreign keys that point to not existing primary keys. With DN and Kodo this will work and just return null

All code is "fully functional", and JDO compliant (DN implements pm.evictAll correctly unless proven otherwise, and the JDO TCK underlines that), and the L1 caches provided all use standard Java

There are none because it did not look at the cache on call to person.getEnterprise(). Thanks a thousand times! With this: <field name="enterprise" default-fetch-group="true"> <column

And the classes, for example the relation field, assuming it is an actual relation field and not an integer. Since the relation is NOT in the default fetch group then it (and the FK) are not fetched

Thanks a lot for your effort. I just had a quick look with the debugger and I did not see where it would store the foreign key (to later be able to use that to do the lookup in the

Why not present facts, starting with the definition of the relation in the classes, the jdo api call(s) in question, and the associated log entries for those calls? Any retrieve will have a FetchPlan,

Hi Andy Thanks. There is no fetch plan involved. On loading the persons the sql gets the foreign key to the enterprise according to the logs. So it will not load the enterprise (and I don't want it

Only you know what is in the fetch plan for a retrieve, and what sql is invoked to retrieve what it retrieves. To check a cache it needs the id of a related object, and ut has to get that from

Hi I try to migrate a legacy application (on Kodo 3.4, develped over 10+ years). I now created all needed plugins so our very much not JDO compliant code runs. However, now that it works I have a

Since you are the only person who sees this, I suggest you get the code and work it out

Hello Andy, In the same issue, we minimized the extensions and ran the query with below two extensions but our sample program is going into infinite loop in execute method. Please find attached the

That is not a "testcase". A "testcase" is something that, when run, returns SUCCESS, FAILURE or ERROR dependent on how it performs and how it is coded based on expectations. That aside, you decide to

Problem Description and Reproduction We were able to reproduce the problem in a small standalone program. We took the samples available from https://github.com/datanucleus/samples-jdo We picked the