Issue Details (XML | Word | Printable)

Key: RDBMS-58
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Minor Minor
Assignee: Unassigned
Reporter: Clive Cox
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
JPOX RDBMS (ARCHIVED)

JDOQL : instanceof and class cast does not work with "new table" inheritance

Created: 22/Jul/06 05:54 PM   Updated: 27/May/10 07:24 AM   Resolved: 19/May/10 09:24 AM
Component/s: Queries
Affects Version/s: None
Fix Version/s: None

File Attachments: 1. Zip Archive C.zip (2 kB)
2. Zip Archive instanceof_tests.zip (5 kB)

Issue Links:
Depend
 


 Description  « Hide
When using an inheritance strategy of "new table" I have problems with queries with instanceof and casting.

For example, I have a base class A, with 2 subclasses B and C.
If I create an A,B and C instances and persist and then do the follwoing query:

Query query = pm.newQuery(A.class, "(this instanceof org.jpox.test.B && (org.jpox.test.B)this == b) || (this instanceof org.jpox.test.C && (org.jpox.test.C)this == c)");
query.declareVariables("org.jpox.test.B b; org.jpox.test.C c");

I get no results returned. (obviously in a real use case after the class cast you would query fields particular to that class)

If each part of the OR is carried out in a separate query, they work on their own.

The SQl produced is as follows:

2006-07-19 17:13:34,700 DEBUG main JPOX.RDBMS.SQL -
SELECT `THIS`.`JDOCLASSX`,`THIS`.`JDOIDX`,`THIS`.`NAMEX` FROM `A` `THIS`
INNER JOIN `A` `THIS_NULL` ON `THIS`.`JDOIDX` = `THIS_NULL`.`JDOIDX`
LEFT OUTER JOIN `B` `THIS_B` ON `THIS_B`.`JDOIDX` = `THIS`.`JDOIDX`
INNER JOIN `B` `UNBOUND_B` ON `UNBOUND_B`.`JDOIDX` = `THIS_B`.`JDOIDX`
LEFT OUTER JOIN `C` `THIS_C` ON `THIS_C`.`JDOIDX` = `THIS`.`JDOIDX`
INNER JOIN `C` `UNBOUND_C` ON `UNBOUND_C`.`JDOIDX` = `THIS_C`.`JDOIDX`
WHERE (`THIS`.`JDOCLASSX` = <'org.jpox.test.A'> OR `THIS`.`JDOCLASSX` = <'org.jpox.test.C'> OR `THIS`.`JDOCLASSX` = <'org.jpox.test.B'>) AND (((`THIS_NULL`.`JDOCLASSX` = <'org.jpox.test.B'>) AND `UNBOUND_B`.`JDOIDX` = `THIS_B`.`JDOIDX`) OR ((`THIS_NULL`.`JDOCLASSX` = <'org.jpox.test.C'>) AND `UNBOUND_C`.`JDOIDX` = `THIS_C`.`JDOIDX`)) -- 5 PS parameters


I don't quite see why:
1. It has to check whether JDOCLASSX is A OR B OR C and then limit it to B OR C
2. maybe issue with OR and INNER JOINS

Test case will be attached.

Sort Order: Ascending order - Click to sort in descending order
Clive Cox added a comment - 22/Jul/06 05:54 PM
Test case

Andy Jefferson added a comment - 13/Dec/07 12:52 PM
Don't understand the query.
Query query = pm.newQuery(A.class, "(this instanceof org.jpox.test.B && (org.jpox.test.B)this == b) || (this instanceof org.jpox.test.C && (org.jpox.test.C)this == c)");
query.declareVariables("org.jpox.test.B b; org.jpox.test.C c");

so what is the cast achieving ? and the comparison with an unbound variable ? All that last part will do is bring in an INNER JOIN.

Do you really just want to do
Query query = pm.newQuery(A.class, "(this instanceof org.jpox.test.B) || (this instanceof org.jpox.test.C)");

Seems much more sensible to me, and works with SVN trunk

Clive Cox added a comment - 13/Dec/07 03:37 PM
I'm afraid as it is so long ago I can't remember why I had this particular query (it maybe in the real example from my project, I was getting the variable from a collection first and then doing the class tests)
However, the query should still work and not fail even if its not the most elegant formulation.

Andy Jefferson added a comment - 14/Dec/07 06:16 PM
As I said, the query doesnt make sense to me, hence I cant see what is "it should work".

Andy Jefferson added a comment - 15/Dec/07 09:12 AM
Downgraded to minor since the real issue is specified in http://www.jpox.org/servlet/jira/browse/RDBMS-70

Tony Aldrich added a comment - 25/Dec/07 04:32 AM
11 tests for instanceof.

Result for 1.2.0-beta5:
Failed tests: 4

MySQL 5.1.12

Andy Jefferson added a comment - 28/Dec/07 07:03 PM
And of the errors, they are typically http://www.jpox.org/servlet/jira/browse/RDBMS-71 due to the fact that when you have no discriminator there is no simple way of generating the SQL necessary to find the information the query needs (but you could just add a discriminator and it all becomes much more efficient - what would be recommended for many use-cases). Of course people could contribute code ...

Tony Aldrich added a comment - 29/Dec/07 04:30 AM

Andy Jefferson added a comment - 23/Mar/09 12:32 PM
Query issues like this will not be addressed with the legacy JDOQL implementation; wait for "JDOQL2" to be complete

Andy Jefferson added a comment - 19/May/10 09:24 AM
DataNucleus 2.x has JDOQL2 pretty much complete