Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of oyvindharboe@gmail.com
 designates 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=QfCKYuRp5eedSWeaDK5QgaYANoqXclEjzEFz5agRS76rdBj2FvtgAxRlslVwsXhYv2
         1C+nYqxp54P02H80eoFHk2We9i+IzWOP8WDVM80ACUu3SwsS9WmlEUsJFHDBYdmjSM2r
         1BtROcchVfijgjHCvk6LinLzVvH6RzioVPme0=
Message-ID: <c09652430808112344i5c3bdfffrb6d2f1721de48914@mail.gmail.com>
Date: Tue, 12 Aug 2008 08:44:20 +0200
From: "=?ISO-8859-1?Q?=D8yvind_Harboe?=" <oyvind.harboe@zylin.com>
Sender: oyvindharboe@gmail.com
To: user@cayenne.apache.org
Subject: Re: NUMERIC default scale behaves differently on Derby & SQL Server
In-Reply-To: <0BAED557-4846-44B7-B85B-E8B58079073C@objectstyle.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <c09652430808080120n1fab7e04y765a7a0c3ccdba9f@mail.gmail.com>
	 <FA23FC3E-F927-48CF-A832-AEC80588FA15@objectstyle.org>
	 <c09652430808081116m71e54fe9v55ecff53e3f98138@mail.gmail.com>
	 <6955CF3B-38A8-43DF-BD1B-D740F3F55BB2@objectstyle.org>
	 <616EDC8D-A5D5-48B9-8B3E-DE691A1D57A3@objectstyle.org>
	 <c09652430808090118h3d29c8aaj1b4d5fb10e6bf627@mail.gmail.com>
	 <0BAED557-4846-44B7-B85B-E8B58079073C@objectstyle.org>

On Tue, Aug 12, 2008 at 12:26 AM, Andrus Adamchik
<andrus@objectstyle.org> wrote:
>
> On Aug 9, 2008, at 12:18 PM, =D8yvind Harboe wrote:
>
>> I guess the problem I see is that I test only against one or two databas=
es
>> so I'd rather see the *same* behaviour across databases regardless of wh=
at
>> JDBC is defined to do...
>
> I understand.
>
>> We flipped scale=3D"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 th=
e
> 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=3D0 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...

--=20
=D8yvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer