All databases have default capitalisations, and a set of capitalisations that they support. The log tells you what they are and what is chosen. Docs tell you more

Hi, It seems DN parse the native queries before execution. I found 2 cases: -1- Query with * projection on flat inheritance model The model (ex: Client -|> Person) mapped on one single table PERSON

Hi, In the orm.xml files all names are lower case, but they are created in upper case in the database. How to make schema tool to keep unchanged the case of column names ? thanks -- Stephane

Hi, The schema tool is creating unique indexes on every foreign-key. I'm trying to reproduce the case on a shareable application, but I can't reproduce. The index name pattern is <Target

That's a little bit more tricky. I would say metadata are loaded as follow (you may know it already): class files and persistence.xml orm (ex: orm-h2.xml) file mentioned in the

You mean the `orm.xml` that is specified in the JPA spec as the default ORM file? (and hence always processed if found, regardless of whether the user included it in persistence.xml). And then the

It seems there are overriding rules, extending the JPA spec and I haven't seen it in DN doc. I have a annotation in classes, a persistence.xml, an orm.xml and an orm-h2.xml. When I load the

So if you're using JPA then you don't use that property ... since it is not mentioned in the JPA docs. Create a new persistence unit per database. Just reference the "orm" file that is needed for that

I'm trying but I can't make it works. I'm using JPA. I added a package-h2.orm at the root of the project. With the option javax.jdo.option.Mapping, DN log a warning property not supported With the

The ORM file is chosen based on the persistence property javax.jdo.option.Mapping, as per the JDO spec.

Hello, Is it possible to have one mapping (file I guess) per database type, which are chosen at runtime "automatically" ? ex: orm-mysql.xml orm-h2.xml ... My need is I'm running the same application

I tested the dontRestrictDiscriminator option but unfortunately it applies regardless of whether the class has a table (new-table in the meta data) or just uses the table of a class in its inheritance

In regard to the reference you gave: This appears that it would affect all queries with any candidate class whereas I definitely still need discriminators in the case where the candidate class is

On Fri, Jul 19, 2019 at 03:16 AM, Andy wrote: If a user was sharing a table for multiple things (or only some of the records applicable to DN usage) then they clearly would not want to include the

Perhaps if you look at http://www.datanucleus.org:15080/products/accessplatform_5_2/jdo/query.html#jdoql_candidate in particular the second "info" point. It specifies a query extension to not add a

When a candidate class for a query is a class that has no base class then, in an RDBMS datastore at least, there should be no need to specify discriminators because they don't need to be part of any

Seemingly you must have fixed your problem by now, so it is assumed to be a problem in user code.

I dont have that database so you have to debug the code yourself. As the code shows (current), that line will not (IMHO) give an

I am trying to connect to informix with no success. Here is the staketrace: Failed initialising database. Please check that your database JDBC driver is accessible, and the database URL and

The following error says I should report this to the DataNucleus developers so just doing my duty :) 22:54:15.392 [main] WARN DataNucleus.Datastore - Default type for java type of