It's not. It's the fact that all numeric are set to float, but Float in CF is the same as double so you don't see the loss of precision as you should. Adobe's mistake in ignoring float precision causes Transfer to work on CF. If Adobe treated float as an actual float rather than as a double then you would see the problem. Transfer has a bug built around a bug in CF, this causes an engine like Railo that treats float correctly to break. What's the point in having float if it's treated as a double? The Transfer cf_SQL_param should be double, then it would work in both.
On Aug 13, 2:22 pm, Jennifr Larkin <[email protected]> wrote: > Since when is "working better than expected" a "bug?" > > On Thu, Aug 13, 2009 at 10:04 AM, > > > > whostheJBoss<[email protected]> wrote: > > > Thoughts on this Mark? This is definitely a bug in CF that is > > reflected as a bug in Transfer. This is, I repeat, NOT a bug in Railo. > > As of now I have to change the numeric mapping to double to get my > > insert to work... > > > On Aug 10, 12:10 pm, whostheJBoss <[email protected]> wrote: > >> Ok, well, I've taken this up with Railo and... > > >>http://groups.google.com/group/railo/browse_thread/thread/d8e20b98308... > > >> Any thoughts on this Mark? > > >> If you want the short version... > > >> "What happens if you change the line from "cf_sql_float"to > >> "cf_sql_double" or "cf_sql_decimal"? I bet it's a truncation issue, > >> where ColdFusion considers cf_sql_float and cf_sql_double to be > >> equivalent, but Railo is correctly using reduced precision for > >> cf_sql_float (causing your erroneous value). To put that another way, > >> I suspect a bug in ColdFusion (not reducing precision on cf_sql_float) > >> is masking a bug in Transfer (using an imprecise type for numerics) > >> that Railo's correct implementation (reducing cf_sql_float precision) > >> unmasks. :) > > >> cheers, > >> barneyb" > > >> "I'm pretty sure all that's needed for confirmation is to change the > >> type from cf_sql_float to cf_sql_decimal or cf_sql_double and confirm > >> that that fixes the issue (just like cf_sql_bigint) does. > >> -- > >> Barney Boisvert > >> [email protected]http://www.barneyb.com/"; > > >> "Hi whostheJBoss > > >> Railo translate CF_SQL_FLOAT to java.sql.Types.FLOAT > >> then java.sql.PreparedStatement.setFloat(int index,float value) is > >> used > >> in this case, > >> i think adobeCF use java.sql.PreparedStatement.setDouble(int > >> index,double value) instead of setFloat. > > >> but this is definitly the wrong way, like barney has written before > >> "cf_sql_double" or "cf_sql_decimal is the way to go. > >> from my perspective it is wrong to change this to "setDouble". > > >> what do you thnk? > > >> greetings micha > > >> -- > >> Michael Offner-Streit > >> CTO > >> Railo Technologies GmbH > >> [email protected]" > > >> On Aug 5, 5:23 pm, Mark Mandel <[email protected]> wrote: > > >> > numeric maps to using cf_sql_float. > > >> > cf_sql_float is a parameter that will correctly handle floating points > >> > across databases. > > >> > It seems that Railo has an issue with how it is mapping cf_sql_float, so > >> > it > >> > cannot handle BigInt values in the database you are using, whereas on CF > >> > it > >> > has no such trouble. > > >> > Mark > > >> > On Thu, Aug 6, 2009 at 10:07 AM, whostheJBoss > >> > <[email protected]>wrote: > > >> > > You happen to know what part of Transfer the bug is affecting? I'd be > >> > > happy to take it up with the guys at Railo, just need to know what I > >> > > should be asking. > > >> > > Is Transfer checking the column type of the objects and then using > >> > > that type to wrap them with a cfsqltype? Does that mean Railo is not > >> > > providing this information to Transfer, so then it is falling back on > >> > > the default cfsqltype for numeric, which in this case happens to be > >> > > float? > > >> > > Basically, is Transfer unable to get the type from Railo so it runs > >> > > this: > > >> > > <cfelseif block.mapparam.type eq "numeric"> > >> > > <cfqueryparam value="#value#" cfsqltype="cf_sql_float" > >> > > list="#param.list#" null="#param.isNull#"> > > >> > > And sets it to float? > > >> > > Thanks! > > >> > > On Aug 5, 4:52 pm, Mark Mandel <[email protected]> wrote: > >> > > > Sounds like a bug in Railo to me. > > >> > > > Mark > > >> > > > On Wed, Aug 5, 2009 at 8:18 AM, whostheJBoss > >> > > > <[email protected] > >> > > >wrote: > > >> > > > > You always manage to come in and say something very simple and I go > >> > > > > "Oh yeah!!!" > > >> > > > > Anyway, CF9 has no problem with this, so it must be... a Railo > >> > > > > thing. > >> > > > > Err, a Transfer / Railo thing. > > >> > > > > So, what can be done to have Transfer see the right data type in > >> > > > > Railo? > > >> > > > > Thanks!!! > > >> > > > > On Aug 4, 2:52 pm, Mark Mandel <[email protected]> wrote: > >> > > > > > You're also on Railo aren't you? > > >> > > > > > Mark > > >> > > > > > On Wed, Aug 5, 2009 at 6:17 AM, whostheJBoss < > >> > > [email protected] > >> > > > > >wrote: > > >> > > > > > > By the way, thanks for helping!!! :) > > >> > > > > > > On Aug 4, 12:31 pm, Jennifer Larkin <[email protected]> wrote: > >> > > > > > > > Which version of MySQL are you using? > > >> > > > > > > > OK, so looking again at the two values in question: > >> > > > > > > >1474075992 > >> > > > > > > >1474076030 > > >> > > > > > > > It is certainly feasible that you have encountered a floating > >> > > point > >> > > > > > > > error. In a ten digit number, the second number is off by > >> > > > > > > > 38. The > >> > > > > > > > thing is, Transfer doesn't cause floating point errors-- > >> > > > > > > > they are > >> > > the > >> > > > > > > > cause of the software that Transfer runs on, and MySQL has > >> > > floating > >> > > > > > > > point errors. I've used Transfer on Oracle and as I said, > >> > > > > > > > I've > >> > > never > >> > > > > > > > encountered this problem. > > >> > > > > > > > So, I looked up MySQL floating point errors and discovered > >> > > > > > > > this > >> > > > > article: > >> > > > > > >http://dev.mysql.com/doc/refman/5.0/en/problems-with-float.html > > >> > > > > > > > Which leads me to believe that if you are using a version of > >> > > MySQL > >> > > > > > > > prior to 5.0.5, that you should upgrade to 5.0.5, which has > >> > > greater > >> > > > > > > > floating point precision. > > >> > > > > > > > On Tue, Aug 4, 2009 at 12:09 PM, whostheJBoss< > >> > > > > [email protected]> > >> > > > > > > wrote: > > >> > > > > > > > > The column in question here is not a key, it's an > >> > > > > > > > > additional > >> > > field, > >> > > > > > > > > nothing special. Just a BIGINT named customID, but it's > >> > > > > > > > > not the > >> > > > > > > > > primary key. The primary key field is userID. > > >> > > > > > > > > As of now, any column with datatype INT or BIGINT is being > >> > > saved > >> > > > > > > > > incorrectly by Transfer. This one in particular was INT, > >> > > > > > > > > then I > >> > > > > > > > > changed to BIGINT trying to fix the problem. So, as of now > >> > > > > > > > > it > >> > > is > >> > > > > > > > > BIGINT and will be staying that way. > > >> > > > > > > > > The same column using the exact same SQL that Transfer > >> > > generates in > >> > > > > a > >> > > > > > > > > regular <cfquery> work fine because it isn't wrapped in > >> > > > > > > > > cfsqltype="cf_sql_float" query param which is invisible to > >> > > > > > > > > the > >> > > > > debug > >> > > > > > > > > output. (Which is why I didn't see it before.) > > >> > > > > > > > > The column it does work for is VARCHAR, which makes > >> > > > > > > > > complete > >> > > sense. > >> > > > > It > >> > > > > > > > > just takes the number and inserts it as a string. > > >> > > > > > > > > Transfer has this statement: > > >> > > > > > > > > <cfelseif block.mapparam.type eq "numeric"> > >> > > > > > > > > <cfqueryparam value="#value#" > >> > > > > > > > > cfsqltype="cf_sql_float" > >> > > > > > > > > list="#param.list#" null="#param.isNull#"> > > >> > > > > > > > > Which takes any "numeric" property of a defined Transfer > >> > > > > > > > > object > >> > > and > >> > > > > > > > > forces it to float, even if the database has it marked as > >> > > BIGINT. > > >> > > > > > > > > On Aug 4, 11:17 am, Jennifer Larkin <[email protected]> > >> > > > > > > > > wrote: > >> > > > > > > > >> I've used transfer with tons of bigint columns and never > >> > > > > > > > >> had > >> > > this > >> > > > > > > > >> problem. I would assume that your key is bigint and not > >> > > > > > > > >> float, > >> > > but > >> > > > > you > >> > > > > > > > >> aren't having a problem with the key being set as float. > >> > > > > > > > >> So > >> > > the > >> > > > > > > > >> question is, why does this work for some columns and not > >> > > > > > > > >> for > >> > > > > others. > > >> > > > > > > > >> What is the datatype on the column that is getting saved > >> > > correctly > >> > > > > and > >> > > > > > > > >> the one that is getting saved incorrectly? > > >> > > > > > > > >> On Tue, Aug 4, 2009 at 10:36 AM, whostheJBoss< > >> > > > > > > [email protected]> wrote: > > >> > > > > > > > >> > Ok, I've figured it out. > > >> > > > > > > > >> > This was absolutely something in Transfer. > > >> > > > > > > > >> > In: > > >> > > > > > > > >> > transfer.com.sql.QueryExecution > > >> > > > > > > > >> > This line: > > >> > > > > > > > >> > <cfelseif block.mapparam.type eq "numeric"> > >> > > > > > > > >> > <cfqueryparam value="#value#" > >> > > cfsqltype="cf_sql_float" > >> > > > > > > > >> > list="#param.list#" null="#param.isNull#"> > > >> > > > > > > > >> > If I replace it with: > > >> > > > > > > > >> > <cfelseif block.mapparam.type eq "numeric"> > >> > > > > > > > >> > <cfqueryparam value="#value#" > >> > > cfsqltype="CF_SQL_BIGINT" > >> > > > > > > > >> > list="#param.list#" null="#param.isNull#"> > > >> > > > > > > > >> > It works. Obviously I can't leave it this way since I > >> > > > > > > > >> > have > >> > > other > >> > > > > > > > >> > fields that are not BIGINT and will cause the same > >> > > > > > > > >> > problem > >> > > for > >> > > > > those > >> > > > > > > > >> > fields, but this is definitely where the problem is. > > >> > > > > > > > >> > So, all numeric values are being set to float. > > >> > > > > > > > >> > On Aug 4, 9:52 am, whostheJBoss > >> > > > > > > > >> > <[email protected] > > >> > > > > wrote: > >> > > > > > > > >> >> Yes, please see my examples above. > > >> > > > > > > > >> >> Transfer updates the correct record in the correct > >> > > database, it > >> > > > > > > just > >> > > > > > > > >> >> happens to put in the wrong value. > > >> > > > > > > > >> >> I know this for sure because I have another field > >> > > > > > > > >> >> called > >> > > "note" > >> > > > > > > that > >> > > > > > > > >> >> is a text field, and if I change: > > >> > > > > > > > >> >> user.setCustomID(1474075992); > > >> > > > > > > > >> >> to: > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
