Ok, so its down to a formatting issue. I apparently missed a
conditional where it would get formatted. But, still think something
should done with this. The usualy error message I get when this
happens is something along the lines of:
Transaction aborted: Object of type
com.vort.ads.vortechs.beans.FlowControlOpenings with identity 6 has
been modified by a concurrent transaction (cache entry is different
from database row). The following fields have been changed
[actual/expected value]:
Which means java, or the compare function, sees the two fields as
being equal and doesn't report anything, which is pretty useless. I'm
not sure what can be done about this as it appears to be a lost in
translation deal going from Java to MySQL. Java = 2.21999999999...
and mysql only saved 2.22
Its just odd, this was acting like anything I had seen before, but was
the same problem I mentioned before.
-Nick
On 5/26/05, Nick Stuart <[EMAIL PROTECTED]> wrote:
> Here ya go. I've had this happen before where MySQL will have
> something like .33333333333 but castor would get confused on it. Have
> always taken care of it on my side by formating/truncating/whatever
> the data before it gets put in.
>
> [XML]
> ...
> <field name="weirPlateHeight" type="double">
> <sql name="weirPlateHeight"/>
> </field>
> ...
>
> [SQL]
> CREATE TABLE `prjdimsfcopenings` (
> `id` int(11) NOT NULL auto_increment,
> `systemId` int(11) NOT NULL default '0',
> ....
> `weirOffset` double NOT NULL default '0',
> `weirSump` double NOT NULL default '0',
> `weirPlateHeight` double NOT NULL default '0',
> ...
> PRIMARY KEY (`id`),
> KEY `systemId` (`systemId`)
> )
>
> [JAVA]
> private double weirPlateHeight;
>
> public double getWeirPlateHeight() {
> return weirPlateHeight;
> }
>
> public void setWeirPlateHeight(double weirPlateHeight) {
> this.weirPlateHeight = weirPlateHeight;
> }
>
> Thats it. Normally, like I said, I can take care of this issue with in
> my own stuff through formatting. But I'm confused because doing a
> normal SELECT from anywhere (command line client, php, where ever) it
> shows as 2.22 in the database. =\
>
> -Nick
>
> On 5/26/05, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> > On 5/26/05, Nick Stuart <[EMAIL PROTECTED]> wrote:
> >
> > > Ok I'm stumped. Here is the end part of the UPDATE statement coming
> > > from the logs.
> > >
> > > .. weirPlateHeight=2.219999999999998 WHERE id=6 AND
> > > systemId=1257...weirPlateHeight=2.22
> > >
> > > Why is the first weirPlateHeight have a million digits on it? Got me!
> > > The database shows 2.22, my field itself in the GUI part of the
> > > program shows 2.2, but apparently when it gets put into the cache it
> > > gets set to 2.21999999.
> > >
> > > This is all happening from a straight load and then save. =\ I
> > > thought it might be a JDBC issue, updated to the latest
> > > mysql-connector, no go. Tried this with both 0.9.6 and 0.9.7M1 and it
> > > does the same thing.
> > >
> > > Where could I hunt this down next?
> >
> > Nick,
> >
> > Please post the following for further analysis:
> >
> > 1) the XML mapping for the weirPlateHeight field
> > 2) the DDL for the table where the weirPlateHeight column resides
> > 3) the Java definition for the weirPlateHeight field
> >
> > I hazard a guess that the conversion being done by Castor is not correct.
> >
> > Bruce
> > --
> > perl -e 'print unpack("u30","D0G)[EMAIL
> > PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > );'
> >
> > The Castor Project
> > http://www.castor.org/
> >
> > Apache Geronimo
> > http://geronimo.apache.org/
> >
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
