whostheJBoss, You seem pretty passionate about this, which is fair enough.
The thing is though - this needs to be tested on: CF7, Oracle, MySQL, SQLServer, Postgres CF8, Oracle, MySQL, SQLServer, Postgres CF9, Oracle, MySQL, SQLServer, Postgres Railo, Oracle, MySQL, SQLServer, Postgres Are you willing to do the testing? Mark On Sat, Aug 15, 2009 at 5:27 AM, Jennifer Larkin <[email protected]> wrote: > > And according to Mark's message, double isn't compatible across > databases and while it is compatible across the two mentioned in this > thread, those are not the only two databases. Which do you think is > more reasonable for him: > supporting a database that doesn't support double > fixing an extreme edge case involving railo and 9 digit integer > precision that until now, you are the only one to encounter > > On Fri, Aug 14, 2009 at 12:17 PM, > whostheJBoss<[email protected]> wrote: > > > > But double works in both... > > > > On Aug 13, 6:02 pm, Mark Mandel <[email protected]> wrote: > >> When I wrote it, 'float' was the only cfqueryparam that worked across > >> databases for both integer and floating point numbers. > >> > >> I can't remember if I tested double or not. > >> > >> This is where we start getting into the differences between CF > engines... > >> and there is not much I can do about that. > >> > >> I break for one, or I break for the other :P > >> > >> Mark > >> > >> > >> > >> On Fri, Aug 14, 2009 at 4:22 AM, Jennifer 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#"> > >> > >> ... > >> > >> read more ยป > > > > > > > > > -- > "Nothing says mother's love like a giant robotic platypus butt!" > Phineas and Ferb > > Now blogging.... > http://www.blivit.org/blog/index.cfm > http://www.blivit.org/mr_urc/index.cfm > > > > -- E: [email protected] T: http://www.twitter.com/neurotic W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
