Intentional. JDO Query programmatic "API" with separated items for "from", "filter", "result" etc never had subqueries in JDO1, and when subqueries were added in JDO2 they were specifiable using that

Thanks for the link. I'll take a closer look at them. I did notice that none of the examples I had found added a subquery filter to a parent query. I wasn't sure if that was for clarity or by

Ample examples of JDO subqueries in these tests. Note that none of the DN docs or these examples codes a subquery text into a "filter" clause of the parent query; they either single-string the whole

I'm trying to get a complex query working with a subquery in the filter which is failing in the JDOQL Parser. I have diluted it to a very simple use case with a subselect which is failing as well.

I need a distributed L2 caching solution and I've narrowed my options down to the big 3: - Redis - HazelCast - EhCache/Teracotta Although I've used Teracotta several years ago, I've somewhat

The log entries are incomplete. You still haven't defined what you are invoking. Only by you DEFINING simple classes, and what operation, and seeing persistence code can anyone have a chance of

Hi Andy, Below are the logs Using query to fetch user setting cache false Query "SELECT FROM User WHERE userId == USERID PARAMETERS Integer USERID FetchPlan [default]" of language "JDOQL" has

The LOG tells you where objects come from. So post the relevant bits of the LOG for the retrieve, then there is basis for comment. And while you're at it, post the actual PM calls, since ignoreCache

Hi, I have two tables Like User and Location and they are mapped by one to many (Location is lazy loaded) Here are the operations performed (Same persistence manager for both requests) Ist request->

Yes, well aware, and I will dig deeper into it, since we would like to re-enable L2 caching. Another issue we observed when using the L2 cache in our Apache Isis app was that sometimes (?) when an

The l2 cache performs a very simple task (providing access to field values across PMs) and is not the cause of "strange effects". If a field is required and is available in the L2 cache then it

Thanks, Andy. It turned out this (and other strange "effects") was seemingly caused by the L2 cache. When we disabled it it went away.

An exception is thrown because it cant find the object in the DB to get the fields from. And it has SQL in the log so you know what it is invoking at that point. So work backwards why it cant find it.

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

Wondering about that bit, is this an indicator that the field was loaded previously and has been unloaded? Under which circumstances would that happen? And why does reloading the field fail?

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.