Bugzilla Version 2.16.7
Bugzilla Bug 1805
  better type handling for OQL where clauses with "IN" operators
     Query page      Enter new bug
Bug#: 1805   Platform:   Reporter: martin-fuchs at gmx dot net (Martin Fuchs)
Product:   OS:   Add CC:
Component:   Version:   CC:
Status: NEW   Priority:  
Resolution:   Severity:  
Assigned To: werner dot guttmann at gmx dot net (Werner Guttmann)   Target Milestone:  
URL:
Summary:

Attachment Type Modified Status Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 1805 depends on: Show dependency tree
Show dependency graph
Bug 1805 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments:


Leave as NEW 
Accept bug (change status to ASSIGNED)
Resolve bug, changing resolution to
Resolve bug, mark it as duplicate of bug #
Reassign bug to
Reassign bug to owner of selected component

View Bug Activity   |   Format For Printing

Description: Opened: 2004-11-28 07:32

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.

     Query page      Enter new bug
This is Bugzilla: the Mozilla bug system. For more information about what Bugzilla is and what it can do, see bugzilla.org.
Actions: New | Query | bug # | Reports   New Account | Log In