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 » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
