|
|
|
Created an attachment (id=771)
CTF test cases to test basic OQL queries and the new functionality That's really great work, Martin. Just running the JDO test suite, but I cannot
see any problems hitting us .. ![]() In addition, can I please ask you to have a look at the documentation, amend it Tests run fine, but a small issue with the last test, where you are apparently
expecting an exception to be thrown: boolean exc = false; I'd consider rewriting this to ... try { Just my 0.02 (European) cents, though. Actually, above test does NOT fail on mySQL 4.1.x ...
![]() > Tests run fine, but a small issue with the last test, where you are apparently
expecting an exception to be thrown: ... > I'd consider rewriting this to ... Yes, good idea. But there are currently some problems with it. The following query generates an "ORA-01722: Invalid Number" exception on Oracle: select * 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 The best way to resolve this would be to check for common/convertible types in But that's a thing for a new bug report. For the moment I would like to propose > 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. ... ");". Any way of moving this to a RDBMS-specific class, similar to all the limit/clause handling business ? > 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. 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. Patch applied (minus the issue mentioned above).
|
proposed patch