I've tried to add the extension definition to my package jdo file but either it isn't working as I expect, or I've defined it incorrectly. This is what I added: <field name="addPerson"

I've been encountering something I don't understand with the Query caches and the L1 cache. I've tried reading the DN docs a few times, but I am still confused by the results I am seeing. My

With a single object relation with the FK at the selected object side there are only 3 things that would be feasible. Load the related object, instantiating it. Put it in the fetch plan for

Thanks Andy. Fair enough (embedded vs related). I forgot to mention the fetch-groups. Indeed, I have no fetch groups explicity defined - either in the mapping file nor in the API usage. Everything

Audit fields "addPerson" and "modPerson" aren't embedded (exist in the same table), they are related (have their own table), using JDO terminology ... or at least without seeing your mapping

I'm having some strange RDBMS N+1 calls most likely due to my mappings, but am not sure if this is a DN Persistence configuration issue or a mapping issue. I'm using MSSQL. My problem is that I have

Thanks for the tip. I was looking for a `clearCache` or a `clearMetadata` method or something to that extent that I didn't notice the `unmanage/unload` methods. I also found the plugin from Dan

There is a MetaDataManager for each PMF. It loads metadata when it needs to. There is a method unloadMetaDataForClass to unload a class' metadata if needing to do so. There is also a method on

I'm working on a fairly large, slow startup legacy application in which I am slowly trying to integrate DataNucleus. I am also leveraging JRebel, which allows me to modify most classes on the fly

Hi, I'm running into a similar problem as you where I need to create an ugly JDOHelper.getObjectIdAsLong() hack as well due to some legacy Kodo code. Did you get something fully functional finally?

Hi, When 2 queries with the same tenant but different tenantReaders are executed, the second one returns the result of the first one. The SQL generated is the same for the second query while it should

You are using a JEE connection pool but are setting the resource type as "local" hence DN will try to commit the connection (since it commits local things). Your connection (JBoss JCA) then throws an

I'm encountering a strange behaviour for which I have not been able to pinpoint the cause and was hoping that someone could help point me in the right direction. I have an application running under

https://www.datanucleus.org/products/accessplatform_5_2/jdo/persistence.html#jboss7 says that "DataNucleus JCA adapter supports both Local and XA transaction types".

FYI The JCA was written by people who no longer develop DataNucleus, and is dependent on volunteers. Consequently you're pretty much on your own. Clearly JDO is just as usable outside of JCA, creating

As a followup question, does the JCA adapter support anything other than XATransactions? I see the following in ra.xml: <transaction-support>XATransaction</transaction-support> Does it support any

I'm trying to integrate DN (JDO) into my JEE application via the JCA adapter, and configure the Persistence manager to understand BeanManagedTransactions. I am retrofitting this into existing code

I'm trying to integrate my instance of JBoss/Wildfly 10 with the Datanucleus JCA-JDO connector. I saw an original post for JBoss AS7 (https://developer.jboss.org/docs/DOC-17094) as linked from the

Thanks; I hadn't seen that extension. I see that the the JDO pm allows for using JPQL but remaining within the JDO framework. Which from a consistency perspective is great. However, from a

Hi, The disable option doesn't work: @MultiTenant(disable = true) In the MultiTenantHandler DN looks for disabled instead of disable attribute name. And then the disable extension is added if it's not