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>


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?


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.


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.


Chris Colman
 

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


Page bloom
 

Presumably the warning is indicating a possible "non optimal performance" SQL query rendered from the JDOQL. If a WHERE clause of discriminator conditions are left out then the range of records the DB must scan is likely much larger for most types of queries.

So I assume what is supported is a WHERE clause of discriminator classId=x conditions only in the case of a query's candidate class.
What is not supported is generating a WHERE clause of discriminator classId=x conditions for a relationship of the candidate class, the kind that might be generated by something like:


q.setFilter("relation instanceof MyClassB && ((MyClassB)relation).attributeOfB != null")

I guess SQL isn't Java so even though the JDOQL can be Java like it's constrained.

Perhaps a nested JDOQL query might work better here? Hmmmm