History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CASTOR-942
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Martin Fuchs
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
castor

better type handling for OQL where clauses with "IN" operators

Created: 28/Nov/04 07:32 AM   Updated: 15/Sep/05 07:15 AM
Component/s: JDO queries
Affects Version/s: 0.9.5.4
Fix Version/s: None

Time Tracking:
Not Specified

Environment:
Operating System: All
Platform: All

Bugzilla Id: 1805


 Description  « Hide
moved this over from bug 1788:

[Werner]
Tests run fine, but a small issue with the last test {in src/tests/jdo/OqlTests.java}, where you are apparently
expecting an exception to be thrown:

...

I'd consider rewriting this to ...

try {
query = _db.getOQLQuery("select x from jdo.TestObject x where value1 in
list(\"XXX\", \"one 21\", 999)");
tryQuery(query, 1);
fail ("blah ...");
} catch(Exception e) {
assertEquals (e.getCLass().getName().equals ("org.exolab. ... ");
assertEquals (e.getMessage().equals ("exception text ..."));
}

[Martin]
Yes, good idea. But there are currently some problems with it.

The following query generates an "ORA-01722: Invalid Number" exception on Oracle:

select *
from test_table
where value1 in ('XXX', 'one 21', 999)

This has been the exception, I was expecting for this last test case.

MySQL instead doesn't generate a error message. In fact it returns the whole
content of TEST_TABLE! IMHO this is a bug, or at least very unexpected
behaviour. There are no datasets with an value1 of "XXX", "one 21" or "999" in
this table.

The best way to resolve this would be to check for common/convertible types in
the "IN" list directly in Castor. Then it would be possible to add your
"assertEquals(e.getCLass().getName().equals("org.exolab. ... ");".

But that's a thing for a new bug report. For the moment I would like to propose
committing this patch, but commenting out the last test case. Just to let the
test suite run without problems on any of the databases.

[Martin]
The best way to resolve this would be to check for common/convertible types in
the "IN" list directly in Castor. Then it would be possible to add your
"assertEquals(e.getCLass().getName().equals("org.exolab. ... ");".

[Werner]
Any way of moving this to a RDBMS-specific class, similar to all the
limit/clause handling business ?

[Martin]
I don't think we need this here. We should just ensure all members of the IN
list are of the same type. Then there should be no problem with any of the
different databases.

[Martin]
But that's a thing for a new bug report. For the moment I would like
to propose committing this patch, but commenting out the last test
case. Just to let the test suite run without problems on any of the databases.

[Werner]
Fine by me. Let's create a new bug report, uncomment this one particular test
again .. and let's address this issue in this new bug report.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.