could do (scoped etc)
<cfset bFALSE = 0>
<cfset bTRUE = 1>
Then use those from there on like <cfif x eq bTRUE> or WHERE thing =
#bTRUE#>
and never use "real" booleans
Still a hack... but eh the net was built on hacks :)
On Fri, 2004-02-13 at 13:46, Nando wrote:
> Hosed seems to be an accurate description ... Funny thing is that i tripped over this
> trying to work my way around a few other problems with booleans i've run across.
>
> I'd much prefer to correctly type them consistantly throughout the app, i've tried,
> but ...
>
> MySQL for instance doesn't support a boolean data type, at least not in the current
> version. It chokes on incoming boolean values. Dang!
>
> In CFMX Q of Q's, boolean values are converted to 1's and 0's, and you run into
> trouble using true or false in the Where clauses of QofQ's (in MX), you need to use 1
> or 0 (at least sometimes you do) ...
>
> So i decided for the sake of across-the-board compatibility to give up trying to use
> booleans in CF in and out of the datastore at least) and just consistantly use the
> numeric values of 1 or 0. That way i should be able to use any database without
> needing to change a lot of SQL, since CF evaluates 0 as false and all other integers
> as true (at least i thought it did!).
>
> Now the newest dilemmna is that using the cfsqltype="cf_sql_bit" in the cfqueryparam
> tag evaluates incoming values of both true and 1 to 255 - and hence *some* of my
> boolean tests are rendering inconsistent results.
>
> Hey, when it rains it pours ...
>
> So i'm in the middle of changing all my cfsqltype's to numeric for my boolean fields
> and that "solves" the problem ... then cfqueryparam evaluates an incoming value of
> true into 1 and all my boolean tests work, no matter how i've coded them.
>
> I guess this qualifies as a "hack".
>
> Anyone dealt with this issue in a better way? The goal is to have "booleans" work
> consistently across DBMS's, in CFSQL and within CF.
>
>
>
> -----Original Message-----
> From: Barney Boisvert [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 13, 2004 8:42 PM
> To: CF-Talk
> Subject: RE: Strange inconsistancy evaluating True/False
>
>
> Ah, the wonders of weakly-typed languages. Not to mention the 50/50
> languages like CF. ;)
>
> Save yourself a world of troubles, treat CF as if it's strongly typed. CFIF
> only accepts boolean conditions (your 'bitPublish' is not a boolean), and
> only compare like types (with some fudge for floating point to integer and
> such).
>
> Not sure where the blame lies, but CF's type system is hosed like a building
> that's on fire. Whether this specific situation that is common across
> weakly-typed languages, or specific to CF, I don't know. It seems to me
> that CF should coerce the int to a boolean first, because boolean is the
> "more strict" type, so both of your expressions would be true.
>
> Cheers,
> barneyb
>
> > -----Original Message-----
> > From: Nando [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 13, 2004 11:25 AM
> > To: CF-Talk
> > Subject: Strange inconsistancy evaluating True/False
> >
> > I just tripped over something a little strange ...
> >
> > <cfset bitPublish = 255>
> >
> > With EQ<br>
> > <cfif bitPublish EQ true>
> > true
> > <cfelse>
> > false
> > </cfif>
> >
> > <br><br>
> >
> > Without EQ<br>
> > <cfif bitPublish>
> > true
> > <cfelse>
> > false
> > </cfif>
> >
> > If you run this test code on CFMX 6.1, you'll see that the
> > first case evaluates to
> > false and the second evalutes to true.
> >
> > using a value of 1 evaluates both to true.
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
