Re: Inflate a boolean

[prev] [thread] [next] [Date index for 2005/02/20]

Tony Bowden wrote:

>On Sun, Feb 20, 2005 at 01:40:58PM -0800, Ofer Nave wrote:
>  
>
>>However, I think a.d.tim is right in that both of those are overly 
>>complex if all you want to do is filter data as it travels between the 
>>database and your CDBI object, without having to create an object 
>>wrapper around it.  Not every column justifies a new class.  :)
>>    
>>
>
>It doesn't have to be a specific new class. Just a new instance of a
>generic boolean class.
>
>  
>
That presumes you have a generic boolean class, and that you're working 
with boolean values.

I still think there should be a simple, fast way to filter/convert a 
column's value, maybe with an inline sub.  Defining a class (or 
depending on an appropriate preexisting one) doesn't fit the bill.

We've got 2 out of 3 cases covered:

1) 'has_a' was designed to support relationships by converting foreign 
key values into CDBI objects representing that record in the foreign 
table.  It is generic enough to handle conversions to non-database 
objects, like DateTime (which rocks), but again, it's all about objects, 
which is overkill for simple value filters.
2) Accessor overrides are even more generic, since you can do pretty 
much whatever you want, and it only requires defining a single function 
(not a class).  However, it does it's thing every time a value is 
accessed, which is inefficient if you can accomplish your goal by 
converting once upon load.
3) (the missing case) So if you just want to convert the value to 
another non-object value upon load... what do you do?  Is there a 
solution involving triggers that I'm overlooking?

>But, most of the time, if you really want "yes" and "no", store those
>in your database, not 1 and 0.
>  
>
That is entirely subjective, and most definitely poor design (in my 
opinion) in many cases.

-ofer