On 24-May-06, at 3:59 PM, Mike Rylander wrote:
On 5/24/06, Toby Thain <[EMAIL PROTECTED]> 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.
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
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.
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 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.
--Toby
--Toby
>
>
> [1] http://json.org
> [2] http://troels.arvin.dk/db/rdbms/#data_types-boolean
>
>> --Toby
>>
>>
>>
>> >
>> > TIA
>> >
>> > --
>> > Mike Rylander
>> > [EMAIL PROTECTED]
>> > 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@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-
devel
>>
>>
>
>
> --
> Mike Rylander
> [EMAIL PROTECTED]
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
--
Mike Rylander
[EMAIL PROTECTED]
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
