Migration from Kodo: Any way to make it store foreign keys to later get already loaded objects from cache (for performance)?


Can you contact me in private? We are interested in professional DN support.

>> If you want the primary key as integer/long, are you talking about "application-id" or "datastore-id"?

I assume I need it for both since most of our application-id classes were datastore-id earlier, so some queries may still use JDOHelper.getObjectId() [or JDOHelper.getObjectIdHack() now] .

>> What happens when a class has a non-numeric PK field? or when it has a composite PK?

In my cases all are smallint, int or long.

>> There are many methods in the codebase that return NumericExpression that you can use as a guide to copy.

I looked at stuff. I think the "inner" numeric needs that PersistableIdMapping, and for creating the outer one as wrapper I only found the way I do it above. Will have another look at other code creating NumericExpression at another time.

But it seems to work so I think all is fine. I may later create a different constructor for NumericExpression (not sure if that needs changes in parent classes too). To create a nop-NumericExpression as wrapper to just change the mapping used.

I was not sure if you maybe say: that is a bug in the == code, it should not set the PersistableIdMapping on the int parameter. Because that code is too complex for my current level of understanding to just fiddle with.


Email is on the website for commercial support.

If you always have a single PK field then I don't see on the face of it why you need "PersistableIdMapping" (that mapping was an ugly hack that someone else introduced maybe 15 yrs ago and I only got as far as removing it from basic persistence operations, but not JDOQL as yet). If the application id you can look at the meta data and grab the metadata and mapping for the PK field. If datastore id you can look at the metadata and mapping for the surrogate field. But then without trying it and seeing examples of its "use" its impossible to say,



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?  Can you share your plugin?  I've looked through the `org.datanucleus.store.rdbms.sql.method.JDOHelperGetObjectIdMethod` implementation, but frankly a little lost by the way it processes everything.  I'm a little unclear on the use of a NumericExpression vs an ObjectLiteral, etc.