On 5/24/06, Toby Thain <toby@xxxxxxxxxxxxx> wrote:
On 24-May-06, at 3:59 PM, Mike Rylander wrote:
> On 5/24/06, Toby Thain <toby@xxxxxxxxxxxxx> wrote:
>>
>> On 24-May-06, at 1:39 PM, Mike Rylander wrote:
>>
> [snip]
Hi Mike,
>
>> > I'd be happy if there was an attr that the driver could set on
>> fields
>> > to say "this is a BOOL, interpret 'f' as false and 't' as true", or
>> > even better, a driver specific interpreter that would take any
>> field
>> > that was maked as a BOOL by said attr (be it a tinyint(1) or
>> > DBI_TYPE_STRING for Pg BOOL) and return (int)1 for true and int
>> (0) for
>> > false. It would be up to the application to look for the boolean
>> > attribute on fields, but at least it wouldn't break any existing
>> > applications, and would allow for future apps to make use of the
>> > information when it is available.
>>
>> You're right, an attribute rather than a new type would avoid
>> breaking existing applications and give you (PostgreSQL users) the
>> extra information you need. It would be meaningless for most drivers
>> though :)
>
> It's true that the attr would go unused in current versions of MySQL,
> but that's not set in stone. If they decide add a true boolean type
> for spec conformance, then this would be very useful, though I imagine
> that it would still look like a tinyint(1) for compat reasons, and
> hense the driver based interpreter.
>
> In any case, my point isn't about where it would /not/ be useful, but
> where it would be useful today. Would there be any objection to me
> creating a patch to implement somthing close to the attr plan I laid
> out above?
>
> Here's the API I'm thinking of, of something close to it:
>
> // _interpreted_ bool will be a signed int of 0 or 1
> int bool_val = -1;
>
> // add an ATTR for bool types, set by the driver if it has the
> information
> attr = dbi_result_get_field_attribs(result, columnName);
>
> if (attr & DBI_BOOL_FIELD) {
> bool_val = dbi_conn_interpret_bool(dbhadle, result, columnName);
> // ... do stuff now that you know the field is
> // a bool, and you have a normalized value ...
> }
I don't have any objection, but it may make more sense as a flag (not
an attribute), necessitating a "dbi_result_field_is_bool", because
attributes are defined per-type (and for backwards compatibility and
portability, we can't assume its type). Maybe Markus has an opinion
here.
Ahh... ok. I haven't looked at flags on fields. I assume that
dbi_result_field_is_null() investigates these flags, and doesn't
simply look at the NULLness of the C value?
>
>>
>> I don't mind the idea of a get_bool/coerce_bool function that could
>> abstract the string/number distinction (PgSQL/MySQL). It would have
>> to interpret any numeric field (and possibly any string), because of
>> course the MySQL driver can't correctly set the attribute.
>
> Hmm... I think it should only interpret fields that are actually
> marked with a DBI_BOOL_FIELD attribute.
That would make it useless for my goal. I already need such a
function in my own application to abstract between My/PgSQL. So I
would be in favour of an approach that might begin a set of functions:
dbi_result_coerce_bool() // which would work with 'real'
boolean (PgSQL), number (MySQL), or string (workaround CHAR(1))
later, if needed,
dbi_result_coerce_int() // might work with numeric or string
fields
dbi_result_coerce_string() // might work with numeric, binary or
string fields
...etc
That makes sense. I will look at dbi_result_field_is_null for inspiration. :)
> The API I've proposed would
> help us move to a broader /strict/ set of types, without breaking
> compatability. To put it another way, I want the database to tell me
> if I need to normalize it's verions of BOOL. Right now only Pg can
> tell me that, but I still want to be told. ;) Also, I don't think
> there's any reason to dismiss the posibility of a real BOOL type for
> MySQL in the future. They've been trying pretty hard, recently, to
> conform to the spec.
They certainly have, and I don't dismiss it. My remarks should not be
taken as discouraging your proposal.
I didn't. I was too harsh there, sorry. :)
>
>>
>> Markus and I have considered a new family of functions that retrieve
>> values less strictly. Perhaps this could be the first in that family.
>>
>
> I wouldn't fight that, but I probably won't use them for this project.
> I need as much information about the data type as I can get. :)
The flag gives you the information you need. The function gives me
the portability I need. :-)
I certainly does. I'll look in the archives for the
dbi_result_coerce_* discussion.
>
>> I haven't looked at the implications for the other drivers.
>>
>
> I gut feeling is that if it's done correctly, there is no implication.
> The attr simply wouldn't be used, and the interpreter function would
> be a no-op defined at the dbi level.
Right, but I just wanted to record that I haven't examined the other
drivers/interfaces at all. I don't expect any problems either.
Cool.
--Toby
>
>> --Toby
>>
>> >
>> >
>> > [1] http://json.org
>> > [2] http://troels.arvin.dk/db/rdbms/#data_types-boolean
>> >
>> >> --Toby
>> >>
>> >>
>> >>
>> >> >
>> >> > TIA
>> >> >
>> >> > --
>> >> > Mike Rylander
>> >> > mrylander@xxxxxxxxx
>> >> > GPLS -- PINES Development
>> >> > Database Developer
>> >> > http://open-ils.org
>> >> >
>> >> >
>> >> > -------------------------------------------------------
>> >> > All the advantages of Linux Managed Hosting--Without the Cost
>> and
>> >> > Risk!
>> >> > Fully trained technicians. The highest number of Red Hat
>> >> > certifications in
>> >> > the hosting industry. Fanatical Support. Click to learn more
>> >> > http://sel.as-us.falkag.net/sel?
>> >> > cmd=lnk&kid=107521&bid=248729&dat=121642
>> >> > _______________________________________________
>> >> > Libdbi-drivers-devel mailing list
>> >> > Libdbi-drivers-devel@xxxxxxxxxxxxxxxxxxxxx
>> >> > https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-
>> devel
>> >>
>> >>
>> >
>> >
>> > --
>> > Mike Rylander
>> > mrylander@xxxxxxxxx
>> > GPLS -- PINES Development
>> > Database Developer
>> > http://open-ils.org
>> >
>> >
>> > -------------------------------------------------------
>> > All the advantages of Linux Managed Hosting--Without the Cost and
>> > Risk!
>> > Fully trained technicians. The highest number of Red Hat
>> > certifications in
>> > the hosting industry. Fanatical Support. Click to learn more
>> > http://sel.as-us.falkag.net/sel?
>> > cmd=lnk&kid=107521&bid=248729&dat=121642
>> > _______________________________________________
>> > Libdbi-drivers-devel mailing list
>> > Libdbi-drivers-devel@xxxxxxxxxxxxxxxxxxxxx
>> > https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
>>
>>
>
>
> --
> Mike Rylander
> mrylander@xxxxxxxxx
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
--
Mike Rylander
mrylander@xxxxxxxxx
GPLS -- PINES Development
Database Developer
http://open-ils.org
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
|
