Hi,
I've created an RFC to change how types are defined in PDO:
https://wiki.php.net/rfc/driver-specific-pdo-param-types
Please share your feedback. I'm happy to hear thoughts about the pdo_dblib
example, but the RFC is more about the possibility of driver-specific types
than these particular ones.
Thanks,
Adam
Please share your feedback. I'm happy to hear thoughts about the pdo_dblib
example, but the RFC is more about the possibility of driver-specific types
than these particular ones.
The whole point of PDO was that anything that was not available across
ALL drivers would be emulated in some way, or flagged in a way that does
not break code, so nothing should be added specifically targeting a
particular driver if it will cause problems when someone selects a
different driver to run the same application.
The question today is if PDO is actually the right base to be building
on, or should a better attempt be made at solving the cross database
problems. ADOdb is still the better benchmark for a lot of the 'loose
ends' that plague PDO.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Please share your feedback. I'm happy to hear thoughts about the
pdo_dblib
example, but the RFC is more about the possibility of driver-specific
types
than these particular ones.The whole point of PDO was that anything that was not available across
ALL drivers would be emulated in some way, or flagged in a way that does
not break code, so nothing should be added specifically targeting a
particular driver if it will cause problems when someone selects a
different driver to run the same application.
I'm starting to think I'm looking at the problem in too narrow a way. Other
supported databases have these column types and likely have these issues.
I'm going to read the PDO code some more and look at the ADOdb type
system[1]. It might be there should be common types for binary and unicode
params, and probably also double params. I'm adding doubles, because it
looks like there's an issue where, since really_register_bound_param()
converts doubles to strings, drivers will bind them as strings and not
doubles. Even though, for example, the MySQL driver attempts to distinguish
between strings and doubles.
I'll follow up when I've gathered more information, but this may be in the
form of a separate RFC.
Thanks,
Adam
[1] http://adodb.org/dokuwiki/doku.php?id=v5:dictionary:dictiona
ry_index#summary_of_types
Hi Adam,
I've created an RFC to change how types are defined in PDO:
https://wiki.php.net/rfc/driver-specific-pdo-param-typesPlease share your feedback. I'm happy to hear thoughts about the pdo_dblib
example, but the RFC is more about the possibility of driver-specific types
than these particular ones.
I've had a cursory look. Looks good to me and it doesn't impact the
other drivers.
One little nitpick is that technically the PDO_PARAM_INPUT_OUTPUT flags
is now in the PDO_PARAM_DRIVER_SPECIFIC range and you add custom flags
that one day might overlap with newly added generic ones.
So maybe we need two driver specific ranges, e.g.
PDO_PARAM_DRIVER_SPECIFIC = 1000,
/* magic flag to denote a parameter as being input/output */
PDO_PARAM_INPUT_OUTPUT = 0x00010000
/* this defines the start of the range for driver specific flags */
PDO_PARAM_DRIVER_SPECIFIC_FLAG = 0x01000000
Since you're changing the API number, it shouldn't be a problem to
modify PDO_PARAM_INPUT_OUTPUT, and this should leave plenty of room for
new generic flags and both driver specific params and flags.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/