Date   

Delete query with IN clause having a single parameter

prashant.mr@...
 

In our project, a Delete query is showing an error when used with IN clause having a single parameter.

I've forked the test-jpa project [1] and updated the SimpleTest.java [2] to recreate this issue.

The following query shows an error message: "Exception thrown when executing query : DELETE FROM PERSON A0 WHERE A0."NAME" = ? AND A0.ID ="

Query query = em.createQuery("DELETE FROM Person AS p where p.name = ?1 AND p.id IN (?2)");
query.setParameter(1, "Person1");
query.setParameter(2, 1);
query.executeUpdate();
But the following two similar queries work:

DELETE FROM Person AS p where p.id IN (?1) AND p.name = ?2

DELETE FROM Person AS p where p.name = ?1 AND p.id IN (?2, ?3)

I'd really appreciate any help to resolve this issue. Thanks.

[1] https://github.com/prashantbhat/test-jpa
[2] https://github.com/prashantbhat/test-jpa/blob/master/src/test/java/org/datanucleus/test/SimpleTest.java


Re: Currently do not support adding restriction on discriminator for table

Chris Colman
 

Adding an import of the MyClassA into the query didn't avoid the warning.


Re: Currently do not support adding restriction on discriminator for table

Chris Colman
 

It's good to know that it's just extra logging rather than something working differently in DN 5.x compared to DN 4.x

I have a condition in the filter using an 'instanceof':

myClassA is a reference to MyClassA which MyClassB extends

myClassA instanceof MyClassB

and then I do cast ((MyClassB)myClassA) in later parts of the JDOQL.

I realized that I have not imported the base class MyClassA into the query - I'll try that.


Re: Currently do not support adding restriction on discriminator for table

Andy
 

The LOG message is a WARNING, not an ERROR. Warning the users that something in their query is (likely) not completely handled.
The user is the only person who knows what that query is. Somewhere there is a CAST to some other type. But the query mechanism has no way of passing a BooleanExpression (whether the cast is valid) across to the next part of the query compilation. So in 5.x it logs a warning, rather than blindly ignoring the potential issue.


Re: Currently do not support adding restriction on discriminator for table

Chris Colman
 

More details:

In a non trivial JDOQL query the candidate class extends a base class that has a reference to MyClassA called, say myClassA.

Part of the query filter contains:

myClassA instanceof MyClassB

I think this is what is causing the warning message to be generated.

Is it saying that this part of the filter will be ignored?

Could it just translate to SQL like:

myClassA.classId in (17300)

Or is there something I've done wrong that makes it not possible for DN to generate this filtering SQL?


Currently do not support adding restriction on discriminator for table

Chris Colman
 

We've just migrated to version 5 and occasionally get the following warning:

Query                      - >> Currently do not support adding restriction on discriminator for table=mytableA f0 to class MyClassB

where:
mytableA is the table used to store a hierarchy of classes with 'MyClassA' as the base class
MyClassB is a class that extends MyClassA

I've looked at the DN source code where this message is produced but I can't really understand what the meaning of this is and if it is severe or can be safely ignored.
I don't recall ever seeing this in DN 4.

We use integer discriminators.

The metadata for MyClassA:
    <class name="MyClassA" detachable="true" persistence-modifier="persistence-capable" table="mytableA">
        <datastore-identity column="MYCLASSA_ID" />
        <inheritance strategy="new-table">
            <discriminator strategy="value-map" indexed="true">
                <column name="classid" jdbc-type="INTEGER" />
            </discriminator>
        </inheritance>
        <version strategy="version-number" column="VERSION" />
        ...
  </class>


MyClassB metadata:

    <class name="MyClassB" detachable="true" persistence-modifier="persistence-capable">
        <inheritance strategy="superclass-table">
            <discriminator value="17300">
            </discriminator>
        </inheritance>
 
        ...
    </class>


Re: Filtered query fails for class with reference to a persistent interface having multiple implementations extending an abstract base class

Chris Colman
 

This is fixed in datanucleus-rdbms version 5.1.6.


Re: EC.preCommit L1Cache op IS NULL!

Steve Springett
 

I think I figured it out. The problem only surfaced when running on Java 9.0.1 inside a Docker container when heap was exhausted (but no OutOfMemory errors displayed).

Moving back to Java 8_151 (inside Docker) but with -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap and a large enough heap specified, and the message went away. It was a seriously strange problem without any indication it was memory related. I have not tried increasing the heap on Java 9 so I don't know if 9 has issues or was just masking the fact it was a memory issue. 8 told me right away by throwing OutOfMemoryError.

Thanks for the heads up on the script loading. For most of my use-cases, I will not know the data in advance of initial start-up, but I plan on using the script loading to populate default/demo data. That'll be really convenient.

Cheers


Re: EC.preCommit L1Cache op IS NULL!

Andy
 

"EC.preCommit" will only ever be in that 1 class (EC = ExecutionContext(Impl)). And the L1 cache will only ever be updated in that 1 class.
Consequently if there is a NULL value in the L1 cache you'd need to debug all places where variable "cache" has "put" called on it with a null value (putObjectIntoLevel1Cache?), and debug why.
If it never puts a null in, but you get one out then you look at whether you are using a PM multi-threaded(!!!) and fix your code to NOT do that. Or look at the class of the "cache" object.

FWIW, DataNucleus provides a mechanism for providing an initialisation SQL file to load up objects, which would run a damn site more efficiently than just instantiating objects and going through JDO (see property datanucleus.generateSchema.scripts.load and its related properties)


EC.preCommit L1Cache op IS NULL!

Steve Springett
 

I have an application that, upon initial startup, creates about a 100,000 objects in a h2 database (using JDO). Each object is committed in its own transaction.

About half way through, the log spits out "EC.preCommit L1Cache op IS NULL!".  The only place I find a reference to this error message is in the source file: ExecutionContextImpl.java

The message doesn't occur all the time, but it does occur most of the time - usually around the same spot. In terms of persisting, I'm using the following code:

pm.currentTransaction().begin();
pm.makePersistent(object);
pm.currentTransaction().commit();
pm.getFetchPlan().setDetachmentOptions(FetchPlan.DETACH_LOAD_FIELDS);

I'm really at a loss here. Any help would be greatly appreciated.


Filtered query fails for class with reference to a persistent interface having multiple implementations extending an abstract base class

Chris Colman
 

I have created a test case (attached) that reproduces this issue.

The class diagram is:



The test case also does a dump of the AirCraftController (atc) table schema and its records in the H2 database to show the columns created.

It appears to have more columns than are strictly necessary and that may or may not be the cause of the issue.

If I remove the AirbusA380 class and make no other code changes the test case succeeds.


DataNucleus Forum deletion

Andy
 
Edited

The DataNucleus Forum is planned to be DELETED permanently in February/March 2018.

The MVNForum software that it used hasn't been updated for years, and the number of spammers who try to post their crap on there takes up too much of my time to prevent.
Make use of all previous questions by that point; but note that the documentation for current versions of DataNucleus mean that the majority of questions there are no longer relevant.


Re: Control quoting of identifiers

Andy
 

The mechanism you quoted is the way to change case. That is what there is. If that doesn't meet your needs you get the code and contribute some feature


Control quoting of identifiers

Mark Thornton
 

Is it possible to control the quoting of identifiers. I am using Postgresql (with JPA) and, by default, all tables and column names are created as upper case. This is unnatural for that database (which converts all unquoted names to lower case).

I am aware of the datanucleus.identifier.case property which allows me to change the case to LowerCase, but that wouldn't work well were I to swap to some other databases.

The SQL standard requires unquoted names to be upper cased by the database; unfortunately both Postgresql and MS SQL Server violate this.

Mark


Re: Should not need to provide JDBC driver name.

Andy
 
Edited


Re: Should not need to provide JDBC driver name.

Andy
 

Since JPA and JDO specs were written for earlier JDKs then I guess they have never been updated to reflect what more recent JDBC specs mandate. Since DataNucleus (v5+) supports JRE 1.8+ ONLY then there is no issue with including JDBC4+ semantics. What other JPA providers do or not you'd have to ask them


Re: Should not need to provide JDBC driver name.

Mark Thornton
 

True, but before putting in the effort I prefer to discover if the project maintainers are in favour of such a change. I also don't know if a similar problem afflicts other JPA implementations.

I have been a little surprised recently, to discover that many people remain unaware that specifying the driver class is unnecessary in JDBC 4.

Mark


Re: Should not need to provide JDBC driver name.

Andy
 

Any "behaviour" can be changed because the code is open source. People can contribute GitHub Pull Requests


Should not need to provide JDBC driver name.

Mark Thornton
 

Since Java 6 / JDBC 4 it has been possible (and normal practice) to open a Connection without specifying the driver or attempting to load its class. Unfortunately if I omit the driver name in DataNucleus (JPA api), it attempts to load a driver class with the name "" (i.e. an empty string), and then fails.

Could this behaviour be changed?

Mark Thornton


Re: Is there any good documentation for how to add support for new data stores?

JashDave
 

Hello Andy, thanks for your quick response. I appreciate your effort and dedication, I know how difficult it is to do all the things single handed.
Sorry for not being clear, what I meant by "good" was, is there any better (more descriptive) documentation (which explains every field and method, and their need), which now I know is not there. Initially I was expecting a tutorial type guide, which takes you through an example implementation of an abstract data store, but it is too much of an expectation from my side. I have many doubts, but I need some time to formulate them and ask. Thanks again.

421 - 440 of 446