Tim Mumford <Tim.Mumfor..ntero.com> wrote:
> Hi All,
> I'm seeing a bit of strange behaviour (see below) that doesn't show up
> with:
> cayenne 1.1
> oracle 10g
> Oracle JDBC Driver version - 9.0.2.0.0
>
> but does show up when I switch the driver to:
> Oracle JDBC Driver version - 10.1.0.3.0
>
> The behaviour:
> I have DomainObjects that have attributes that are BigDecimals.
> Upon a commit, the data seems to be inserted correctly for these
> attributes except when the value to be inserted is 0 (zero). In these
> cases the value that is ultimately inserted turns out to be 8.
> (8.00000000 actually)
>
> The db entity's attribute is of the type NUMERIC with a max_length of 24
> and a precision of 8.
>
> Of consideration is that we are running JDK1.5 and the drivers are
> labeled for '1.4', but it does seem odd to me that the oracle 9 driver
> doesn't give us this problem.
Oracle drivers are a strange and convoluted software set.
For what it's worth, we're running Cayenne 1.1 and the following currently
problem-free.
Ebpp DEBUG [Orion Launcher 02-10 10:45:32] QueryLogger: Database Product
Version is Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
Ebpp DEBUG [Orion Launcher 02-10 10:45:32] QueryLogger: JDBC Driver Name is
........ Oracle JDBC driver
Ebpp DEBUG [Orion Launcher 02-10 10:45:32] QueryLogger: JDBC Driver Version
is ..... 10.1.0.3.0
Ebpp DEBUG [Orion Launcher 02-10 10:45:32] QueryLogger: JDBC Driver Major
Version is 10
Ebpp DEBUG [Orion Launcher 02-10 10:45:32] QueryLogger: JDBC Driver Minor
Version is 1
This is the oci client as the thin client (and possibly the oci one as well
-- who knows?) was generating weird intermittent errors deep within the
driver.
Your best bet is to try to match things as closely as possible (1.4 drivers
under jdk1.4, database version matches jdbc driver version), but even that
is no guarantee.
Some of the problems we had with using the JDBC 9 drivers with Oracle 9i was
that timestamp values got stored with a different fractional value than what
was sent via SQL. Ie, "select field from table" didn't return the same
value1 as "update table set field = value1" specified.
You can start by turning on Cayenne logging and insuring that the SQL being
generated is really binding 0 to your BigDecimal field. If that's the
case, and it's showing up as 8.0000000 in your database, then it's time to
file yet another TAR... :)
-Mike
This archive was generated by hypermail 2.0.0 : Fri Feb 11 2005 - 21:00:01 EST