Thanks Andy. Does this mean we should try to load these fields eagerly? It also seems this only happens under higher load. What would be a good place to start looking for why this exception is being

This is an indicator that a field is NOT loaded and something wants it. Only you know your class, and what field you have there, and what is invoked to try to get that field

On Wed, Jul 7, 2021 at 08:24 AM, <mwhesse@...> wrote: loadUnloadedFieldsInFetchPlanWondering about that bit, is this an indicator that the field was loaded previously and has been unloaded? Under

I'm getting the below error (rather "randomly') when loading certain fields of my entities. I don't know where to start looking. Any kind of advice is appreciated. On DN 5.2 with SQL Server. Let me

It is all utterly inconsistent, of course, with javax.persistence developed outside of Oracle (under Eclipse) and so being renamed (just to add pain to its users), and javax.jdo developed outside of

So on further reading I realized Oracle has just separated out JEE stuff to Eclipse. I had previously misunderstood Oracle's stance to imply that all non "core Java" libraries using javax.* packaging

Ah cool. It was my understanding that any 'javax.*' packages would have to be renamed.

No. It's nothing to do with 'java ee'.

Will the JDO API have to undergo a similar Jakartification?

Hi, I'm not sure if this is a bug or by design. I have raised an issue in the Datanucleus-rdbms project at https://github.com/datanucleus/datanucleus-rdbms/issues/384, but not sure which forum is

Since RDBMS datastores each have their own dialect, and since they have such a wide variety of random stuff you can put into an SQL statement, it is necessary to categorise statements and use the

My DBA has prepared some custom SQL queries that he does not want to put into StoredProcs. So I want to execute them via a normal Query.executeResultList(). However, I noticed that if the query does

Thanks for the link. I had tried a github search for PreparedStatement on the samples repo, but hadn't thought of searching for tests. I had not realized that the JDOConnection could simply be cast

The JDO spec is public, as is the JDO TCK which will have tests. Also this test.

I have a few pieces of code that use native PreparedStatements, but am having trouble using them in conjunction with the PersistenceManager. The current approach is: Connection conn =

Thank you Andy for your reply. I've modified my master POM file to use the pluginManagement section and magically everything now works (probably there was some wrong dependency somewhere, probably

Look at JDO spec 13.4.3, you can calland be notified via the (standard) beforeCompletion/afterCompletion methods. Note that this is for a transaction itself. It will not include NON-TRANSACTIONAL ops

I'm working on migrating legacy code that was using the OpenJPA Transaction Listener to identify a transaction boundary (commit) to trigger some post-commit functionality. The logic is a bit messy,

DN v6.0.0.m1 is released. Notable changes are Minimum Java requirement v11. Upgraded ASM to v9.1 to provide for all current bytecode. Support for Jakarta Persistence v3.0+ API. The JPA API is

Thanks for the info. Since I don't have Java16, and unlikely to ever have it (not an extended lifetime release AFAIK), I cant confirm or otherwise. You can provide a GitHub pull request for the