Date   

Re: JDOQL ordering using primary key field

Page bloom
 
Edited

Thanks Andy, that worked well.

I used it within my setOrdering call:

setOrdering("score ascending, JDOHelper.getObjectId(this) ascending);


Re: JDOQL ordering using primary key field

Andy
 

JDO has

"SELECT FROM mydomain.MyClass ORDER BY JDOHelper.getObjectId(this)"


JDOQL ordering using primary key field

Page bloom
 
Edited

If a class does not have an attribute defined to be the primary key field but, rather, relies on DN creating the primary key column in the RBDMS table implicitly, is there any way to specify the default primary key colunn in the ordering clause:

e.g.

Query q = ....
q.setOrdering(score ascending, PRIMARYKEYCOLUMN ascending)

I know the column exists in the RDBMS table and could write the native SQL to set up ordering that included it but at the Java level there is no Java attribute to refer to it in JDOQL that I am aware of. 

Perhaps DN has some keyword that can be used to represent the underlying, implicitly created primary key field.




 


Re: Use multiple columns for Discriminator in Inheritance Tree with single-table

Andy
 
Edited

Yes, JDO, JPA (and Jakarta Persistence) all allow 1 discriminator (value) only. JDO metadata strictly speaking permits multiple columns for some reason, but there is only space for 1 value and that's what DataNucleus has always stuck to. Multiple discriminator values makes little sense to me FWIW.

I don't see any way of having multiple discriminator columns by using extensions with current DataNucleus code.

Options
  • Update DN code to cater for multiple columns (and values) for each class, and then provide a mechanism for getting class name from the column values. This is potentially a lot of work, and would have to retain compatibility with standard JDO / JPA handling.
  • Update your DB to only have a single (surrogate) column and use standard JDO discriminator handling.
  • Update your class(es) to map on to a single one of the (surrogate) columns and optionally read in the other column (if it is still important) into a field of the class(es).


Use multiple columns for Discriminator in Inheritance Tree with single-table

Kraen David Christensen
 

We have a table like: node(nodetype, subnodetype, ...)
From this one table we want to have several persistent java classes.
Both node.nodetype and node.subnodetype is needed to discriminate the java class we need (sometimes only nodetype is enough).
As far as I can see JDO/JPA only allows ONE discriminator column.
Is there anyway I can customize and build my own discriminator type (eg. by specifying something like:
@Discriminator(customStrategy = "MyStrategy")
on node table?
I've tried with no luck - but perhaps this is not possible.
It might be that I should write my own StoreManager extension for this?
And would that be recommended/easy?

Best regards, Kræn David Christensen


Clone of test-jdo is not working

mores
 

I am trying to build a test case for JDO.

When I clone https://github.com/datanucleus/test-jdo then mvn clean compile test I get a failure, also created https://github.com/datanucleus/test-jdo/issues/4.


Re: Java 17 Compatiblity

Andy
 
Edited


Java 17 Compatiblity

Shivaraj Sivasankaran
 

We use below components from datanucleus, since we have a plan to upgrade to Java 17 need to know the compatibility to run the below components on java 17 runtime environment.

Vendor

Software Name

Version

Data Nucleus

datanucleus-api-jdo

5.2.7

datanucleus-core

5.2.9

datanucleus-joda-time

5.2.0-release

datanucleus-hbase

5.2.2

datanucleus-jdo-query

5.0.9

datanucleus-maven-plugin

5.2.1


Re: Spanner Adapter type conversion/matching problem

Andy
 
Edited

Hi,

if you have a class with a field of type "int" then, to find its JavaTypeMapping, DataNucleus will look at the column mappings that the adapter has registered. In your adapters case, it has Integer so will find JDBC type of INTEGER as the DEFAULT for that java type, and the IntegerColumnMapping for the column. It will also make use of either what the JDBC driver provides for JDBC INTEGER or what your adapter provides for INTEGER. To persist data it will probably call IntegerColumnMapping.setInt and to read data from the database it will probably call IntegerColumnMapping.getInt.

You should look in the log and find entries like this
Field [mydomain.model.A.id] -> Column(s) [A.ID] using mapping of type "org.datanucleus.store.rdbms.mapping.java.LongMapping" (org.datanucleus.store.rdbms.mapping.column.BigIntColumnMapping)
This tells you what mappings are being used, and hence what behaviour you should expect for read/write operations.

The CloudSpannerTypeInfo entries are added when the JDBC driver doesn't provide them. Does it provide them itself? Run DataNucleus SchemaTool "dbinfo" mode, which tells you what is either provided by the JDBC driver or added by your adapter. You can look at the info under here for other datastores for reference. Maybe contribute this output to GitHub also?


Spanner Adapter type conversion/matching problem

yunus@...
 

Hi everyone,

Recently I have created a pull request for Spanner database adapter. While running the Datanucleus tests I have encountered an issue which made me realize that I have not fully understood the type conversions.
In the Datanucleus tests there is a Person class with int age attribute. This field is correctly created as INT64 type in Spanner, but during a read, I get an error saying: it was impossible to set the field "AGE" type "java.lang.Long".
Looks like Spanner adapter considers this field as LONG java type while reading. As a side note, Spanner has a single integer type, which is INT64. In database metadata, it is mapped to BIGINT.

So here is my question. I have added sqlTypesforJdbcTypes which performs a mapping. But I also have registerColumnMapping which maps a java type to jdbc and sql type.
Could you please explain how the Java type, SQL type and JDBC type are related to each other? How does datanucleus make a decision on type mapping?

Best regards
yunus


Re: Datanucleus with Informix

gustavo.echenique@...
 

Thanks for your information Andy!

Is very important for me.


Re: Datanucleus with Informix

Andy
 
Edited

Hello,
DataNucleus has a datastore adapter for Informix, shown here. This was developed quite a few years ago by someone, who also provided these docs specific to the Informix adapter.
I don't have Informix so can't comment on how up to date it is. But then you haven't presented any meaningful information about what the "problem" is. A problem has an error message for example. DataNucleus (RDBMS) requires a valid JDBC driver to connect to the database.

What you do in "Spring Boot" you'd have to ask the people who develop that. DataNucleus is simply a standards compliant JDO / JPA provider providing support for those APIs


Datanucleus with Informix

gustavo.echenique@...
 

Dear colleagues:

I am developing a project with Spring Boot and Informix IDS 7.31TD9, but I find that I cannot connect to the database.
I tried to load the dependencies of all the versions of Informix that are in the Maven repository and it did not work, nor did the strategy of loading the Informix JDBC 3.00JC3 jars in the project classpath, which have allowed me to connect from JavaEE 7 projects.
 
I need to know if Datanucleus supports this version of Informix, and if yes, if there is documentation to replace Hibernate in Spring Boot.
 
Thank you in advance for your attention.


Re: Programmatic retrieval of a persistent class' discriminator

Andy
 
Edited

The discriminator is clearly in the retrieval SQL when you query for objects, but is only used to decide which type of class to instantiate.
It would be part of the metadata for the class, so you could use the JDO MetaData API to extract the discriminator value for a specific class

pmf.getMetadata(MyClass.class.getName()).getInheritanceMetadata().getDiscriminatorMetadata().getValue();


Programmatic retrieval of a persistent class' discriminator

Page bloom
 
Edited

Clearly we can associate a unique (usually integer in our case) class ID / discriminator to each persistent class.

Given that this class ID is always unique across all classes within our system I have found a use case where using that concise unique integer would be beneficial/optimal for use outside of persistence (e.g. concisely identifying classes across microservice linked components without having to supply a FQCN) - the trouble is, it's embedded in the metadata (.jdo) file at build time and I haven't been able to work out a convenient way of retrieving it at runtime.

Does the JDO API or any DN extension support, given a persistent class i.e. Class<>  (not an actual persistent object instance), retrieving the discriminator (ClassID) associated with that class?

I realize that the discriminator is not only optional but it also supports a variety of types, not just integer but perhaps there is an internal discriminator "object" that holds this info that we could extract from.


Re: How to identify fields that are made dirty during an InstanceCallback from within a listener?

Andy
 
Edited

The JDO spec (12.15) explicitly insists that InstanceLifecycleListener methods are called BEFORE InstanceCallbacks, so we can't just change the code to calls to the opposite order, hence using LifecycleListeners for this will always miss anything the user does subsequently (in jdoPreStore).

You could look at adding an extra (DN-specific) listener giving you the explicit info you require, for classes that you want to do auditing on. e.g AuditPersistListener, and then update JDOCallbackHandler to call all AuditPersistListener when all other listeners/callbacks have been called, i.e https://github.com/datanucleus/datanucleus-api-jdo/blob/master/src/main/java/org/datanucleus/api/jdo/JDOCallbackHandler.java#L159

Means a vendor extension so dependent on DN code, but then your solution will be either way.


How to identify fields that are made dirty during an InstanceCallback from within a listener?

ebenzacar@...
 

Hi Andy,

I'm running into a bit of a catch-22 solution here and would love some ideas if you have something.

I'm trying to identify all dirty fields of an object during a StoreLifecycleListener.  I have both the preStore() and postStore() methods implemented.
The catch-22 situation I'm running into is that only the preStore() has the dirty flags identified.  Once DN persists the data, it clears all the dirty flags and then calls the postStore() listeners.  So by the time it gets to the postStore() listener, all fields are "clean".


However, the preStore() LifecycleListener is fired _before_ the StoreCallback.jdoPreStore().  Which means that if a field is changed/modified in the jdoPreStore() I won't have access the updated data during the StoreLifecycleListener.preStore() event.

If I wait until the postStore() event to retrieve the value (since it is changed AFTER preStore()), then I have no way of identifying which field(s) were changed since the dirty flags are cleared by that point.

I'm a bit in a pickle; I want to try to identify exactly which field(s) and their value(s) were updated/sent to the DB, but cannot find the right approach.

Any ideas/thoughts?

Thanks,

Eric



Re: Where/how to report updates needed to documentation?

ebenzacar@...
 


Re: Where/how to report updates needed to documentation?

Andy
 
Edited

All is in GitHub, of course (link). Extensions docs are in Asciidoc format, under https://github.com/datanucleus/docs-accessplatform/tree/master/src/main/asciidoc/extensions


Where/how to report updates needed to documentation?

ebenzacar@...
 
Edited

Hi,

In reading through the Plugin documentation on the website, I noticed an oversight in the docs.  How/where can I report this?  I tried to look to see if there was a github repo for the website, but couldn't find it.

In the Java Types section, there is missing the parameter/documentation for:
  - container-handler

I'm not 100% sure how to document it other than copy/paste the definition from the `org.datanucleus.store.types.ContainerHandler` class and identify that it is mandatory for a container-object and must implement the container-handler.

Thanks,

Eric

1 - 20 of 461