You will need to check that when using cf_sql_double works for inserts, updates and selects for:
all integer values all floating point numbers as well Across all the databases. My issue is not with whether or not it is a bug. My issue is if it's going to break Transfer for 99% of Transfer's user base, which use Adobe ColdFusion. Mark On Sat, Aug 15, 2009 at 10:13 AM, whostheJBoss <[email protected]>wrote: > > Sure, can you give me a tiny bit of direction on what needs to be > tested? What kind of values I need to try, etc. > > I don't have access to an Oracle server at the moment, so that's the > only one I can't test. Jennifer seems to be a veteran at this though, > so perhaps she could take my test case and try it on her server? > > The reason I'm so passionate about it is because I want it to work > correctly. I don't like having to modify my Transfer away from the > version you provide just to get this working. > > I am at CFUnited right now, have been hanging out with a lot of > different people and getting opinions. EVERY single person I have > talked to, including top-level developers whose names you know (and > some people you know personally), agree that this is a bug in Adobe CF > and a bug in Transfer that reflects that. You, as the developer, > wouldn't have had any way to really know this though without hitting > my test case. So, I can't blame you for defending your point. > > The reason I'm seeing the error now is because I'm building a Facebook > application and they now have long IDs and recommend using BIGINT to > store the ID. I'm sure more people will begin to see this behavior as > well soon. > > If all FLOAT become DOUBLE to Adobe, then there is technically no such > thing as FLOAT in Adobe CF. So why do they even represent it as an > option? > > If FLOAT becomes DOUBLE, then using double in Transfer is the same as > using FLOAT as far as ColdFusion is concerned, so none of the > databases should break because they are ALREADY getting a double. > > If: cf_sql_float in CF is really cf_sql_double, then changing your > line of code to cf_sql_double won't change ANYTHING about how CF > servers handle it. They are already doing everything as double. > > The only thing this would change would be that Railo would begin to > work, since it DOES distinguish FLOAT from DOUBLE. > > On Aug 14, 3:00 pm, Mark Mandel <[email protected]> wrote: > > 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 > > > > ... > > > > read more ยป > > > -- 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 -~----------~----~----~----~------~----~------~--~---
