To be clear, If the testing works across the board, then I have no problem changing it, but if it doesn't, then I can't change it, and we need to start looking at alternate solutions.
Mark On Sat, Aug 15, 2009 at 10:29 AM, Mark Mandel <[email protected]> wrote: > 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 > > -- 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 -~----------~----~----~----~------~----~------~--~---
