cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Øyvind Harboe" <>
Subject Re: NUMERIC default scale behaves differently on Derby & SQL Server
Date Tue, 12 Aug 2008 06:44:20 GMT
On Tue, Aug 12, 2008 at 12:26 AM, Andrus Adamchik
<> wrote:
> On Aug 9, 2008, at 12:18 PM, Øyvind Harboe wrote:
>> I guess the problem I see is that I test only against one or two databases
>> so I'd rather see the *same* behaviour across databases regardless of what
>> JDBC is defined to do...
> I understand.
>> We flipped scale="2" for all our NUMERIC types
>> since that is what our application assumes.
> I think this is the "correct solution" as it explicitly tells the driver
> what to do leaving no room for ambiguity. I am still unsure about what the
> Cayenne default behavior should be (when there's no scale set).

Good question indeed. Perhaps this is just a bug in Derby? Shouldn't
scale -1 mean infinite precision for BigDecimal?

I *could* add a BigDecimal extended type to handle this in a way
that follows the *applications* rules, right? (whatever those rules
might be).

Make scale=0 default? Forces user to choose?

Perhaps add a file to cayenne which lists known ideosynchrazies
across databases?

Keep it under Subversion such that it is in sync w/source code
from a historical point of view, a javadoc comment would do...

That would only document it, not necessarily help the developers
catch the problem up front(as that would require reading documentation
and everybody knows how well that works...)

I can't think of anything that is a 30% improvement over the current
state of affairs, so perhaps doing nothing is just as well...

Øyvind Harboe
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer

View raw message