FAQ
Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversion and creating problems hinting at the desired binding type
for BLOBS and numeric data types.

Search Discussions

  • Wez Furlong at Nov 4, 2010 at 3:25 am

    On Nov 3, 2010, at 9:52 PM, Stanley Sufficool wrote:

    Before I gut PDO_DBLIB one more time to implement native parameter
    binding for stored procedures, what are the thoughts on returning the
    column values from the database as the native PHP type when possible?
    Currently everything is returned as a string, incurring overhead for
    conversion
    The design philosophy was to pull the data out as strings as this
    gives the highest data fidelity (especially with the various numeric
    types) and is a pragmatic choice for the majority of web apps which
    are largely in text land anyway, and typically are not bottlenecked on
    the performance of converting database column values.

    Some drivers, particularly postgres, are unable to request string data
    and therefore return their results in the type that most closely
    matches the C datatype forced on it by the API.

    This has been a source of complaints from some about the consistency
    of the returned data for apps that are designed to run against
    multiple database backends.

    I would advise against changing the behavior of the driver if
    possible, and against changing it away from the established
    stringiness of PDO without good reason.
    and creating problems hinting at the desired binding type
    for BLOBS and numeric data types.
    Can you elaborate on this? You can explicitly set the desired binding
    via bindColumn.

    --Wez.
  • Stanley Sufficool at Nov 4, 2010 at 3:49 am

    On Wed, Nov 3, 2010 at 8:25 PM, Wez Furlong wrote:
    On Nov 3, 2010, at 9:52 PM, Stanley Sufficool wrote:

    Before I gut PDO_DBLIB one more time to implement native parameter
    binding for stored procedures, what are the thoughts on returning the
    column values from the database as the native PHP type when possible?
    Currently everything is returned as a string, incurring overhead for
    conversion
    The design philosophy was to pull the data out as strings as this gives the
    highest data fidelity (especially with the various numeric types) and is a
    pragmatic choice for the majority of web apps which are largely in text land
    anyway, and typically are not bottlenecked on the performance of converting
    database column values.

    Some drivers, particularly postgres, are unable to request string data and
    therefore return their results in the type that most closely matches the C
    datatype forced on it by the API.

    This has been a source of complaints from some about the consistency of the
    returned data for apps that are designed to run against multiple database
    backends.

    I would advise against changing the behavior of the driver if possible, and
    against changing it away from the established stringiness of PDO without
    good reason.
    One reason was to bring the driver in line with the behavior of the
    PDO sqlserv driver (
    http://msdn.microsoft.com/en-us/library/cc296193.aspx )

    Eventually I would like yo make the 2 interchangeable and have PHP/PDO
    applications run the same on Win32 and Linux.
    and creating problems hinting at the desired binding type
    for BLOBS and numeric data types.
    Yes, you are right. I can bind columns as strings and parameters as a
    specific data type independently.
    Can you elaborate on this? You can explicitly set the desired binding via
    bindColumn.

    --Wez.
  • Lester Caine at Nov 4, 2010 at 7:40 am

    Stanley Sufficool wrote:
    One reason was to bring the driver in line with the behavior of the
    PDO sqlserv driver (
    http://msdn.microsoft.com/en-us/library/cc296193.aspx )

    Eventually I would like yo make the 2 interchangeable and have PHP/PDO
    applications run the same on Win32 and Linux.
    Two wrongs don't make it right?
    Either we have PDO2 with a generic change on all drivers, or we get M$ to ollow
    the standard and fix the sqlserv driver.
    This STILL does not clear up some of the cross database problems but at least we
    would all be working to the same set of rules?

    --
    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//
    Firebird - http://www.firebirdsql.org/index.php
  • Richard Lynch at Nov 5, 2010 at 12:37 am

    On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
    Before I gut PDO_DBLIB one more time to implement native parameter
    binding for stored procedures, what are the thoughts on returning the
    column values from the database as the native PHP type when possible?
    Currently everything is returned as a string, incurring overhead for
    conversion and creating problems hinting at the desired binding type
    for BLOBS and numeric data types.
    It *SEEMS* like a Good Idea (tm) until you think it through and
    realize that there is NOT a one-to-one correspondence between PHP
    native types and DB native types.

    Even what seems like a no-brainer for, say, INT is not. Does PHP INT
    have the same range as the DB INT? Dollars to doughnuts says "No." is
    the correct answer.

    BIGINT? Not a chance. PHP doesn't really do bigint, unless you want
    to return some GMP thing, which is probably not a Good Idea, as GMP
    isn't always there, I don't think.

    Then you start looking at things like an enum, or GeoIP, or IP address
    as native DB types, and it gets really ugly, really fast.
  • Stanley Sufficool at Nov 5, 2010 at 2:09 am

    On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch wrote:
    On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
    Before I gut PDO_DBLIB one more time to implement native parameter
    binding for stored procedures, what are the thoughts on returning the
    column values from the database as the native PHP type when possible?
    Currently everything is returned as a string, incurring overhead for
    conversion and creating problems hinting at the desired binding type
    for BLOBS and numeric data types.
    It *SEEMS* like a Good Idea (tm) until you think it through and
    realize that there is NOT a one-to-one correspondence between PHP
    native types and DB native types.

    Even what seems like a no-brainer for, say, INT is not.  Does PHP INT
    have the same range as the DB INT?  Dollars to doughnuts says "No." is
    the correct answer.

    BIGINT?  Not a chance. PHP doesn't really do bigint, unless you want
    to return some GMP thing, which is probably not a Good Idea, as GMP
    isn't always there, I don't think.

    Then you start looking at things like an enum, or GeoIP, or IP address
    as native DB types, and it gets really ugly, really fast.
    I realize that non Zend types would have to be returned as a string
    representation. The hangups I am having is with large objects returned
    as streams in some drivers (but not dblib) and inconsistent date/time
    string representations across drivers depending on server
    configuration files (freetds.conf).

    Another BIG issue I am having when using strings with DBLIB is that
    they go through iconv, destroying binary values when translated to the
    server character set from the assumed latin1 PHP client character set.
    SQL Server for some reason allows characters to be stored in a
    varchar/text fields even though the character is not defined in the
    servers code page, whereas iconv pukes with an error.

    It would be a wonderful development to have an RFC on the preferred
    string representation of various objects as returned by the driver so
    that when using ANSI SQL with PDO you can expect the same
    representation across all drivers.
  • Richard Lynch at Nov 5, 2010 at 2:44 am

    On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote:
    On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch wrote:
    On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
    I realize as the guy who has to deal with the driver code and what it
    should do for people not following the advise below, it's probably
    preaching to the choir, but...

    Read the below comments this way: Anybody dumb enough to rely on the
    kind of stuff you are asking about is already in Big Trouble (tm).
    I realize that non Zend types would have to be returned as a string
    representation.
    At the risk of repeating myself, even Zend types aren't going to match
    up -- The devil is in the details. The range for an INT in the DB
    won't match the range for a Zend INT, for at least some databases,
    almost for sure. I know 2s complement is 2s complement all over, but
    there has to be SOME DB out there that has a range +/- 1 compared to
    Zend INT.
    The hangups I am having is with large objects returned
    as streams in some drivers (but not dblib)
    I never really use large objects, as anything that large doesn't
    belong in the database in the first place... :-)

    Rule Of Thumb:
    If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
    doesn't belong in the DB.
    Put it in the custom highly-optimized specialized database engine
    commonly known as "the file system" where it belongs. :-)
    and inconsistent date/time
    string representations across drivers depending on server
    configuration files (freetds.conf).
    Ewww... I generally use the DB date format feature to format dates in
    a consistent manner, rather than rely on whatever random date/time
    output the DB/driver chooses.
    Another BIG issue I am having when using strings with DBLIB is that
    they go through iconv, destroying binary values when translated to the
    server character set from the assumed latin1 PHP client character set.
    SQL Server for some reason allows characters to be stored in a
    varchar/text fields even though the character is not defined in the
    servers code page, whereas iconv pukes with an error.
    I'm not an i18n expert, but...

    Why is iconv being injected at this point?!

    And why is PHP client library using latin1 for data that just isn't
    latin1? That's just asking for problems...

    I would expect any driver to just give me the raw data from the
    database, in the charset defined by the DB, and not to try to
    down-sample it to some other charset for me...

    Though I guess if you've told the PHP client to make it be 'latin1'
    the best it can do is trash it through iconv and you get what asked
    for...

    My only answer to that is to change your code to not ask for 'latin1'
    in the first place, when the data isn't latin1. Change the PHP client
    charset to what it ought to be, and get the data you wanted, not some
    lossy down-sampled useless conversion of the data you wanted.

    I cannot comment on SQL Server behaviour with respect to the "servers
    code page" [sic], whatever that is, except to say that MySQL lets you
    define your charset on a table by table basis, and, I think, in recent
    versions, even on a field by field basis. OpenSource ftw, perhaps? :-)
    It would be a wonderful development to have an RFC on the preferred
    string representation of various objects as returned by the driver so
    that when using ANSI SQL with PDO you can expect the same
    representation across all drivers.
    I'm all for documenting what SHOULD happen across all drivers, if
    a) the docs are sensible, and
    b) it can be implemented in all drivers

    I suspect that even a) would generate a TON of discussion on this list
    that would never be resolved, and that b) is simply not possible due
    to some really brain-dead drivers.

    But that's just my naive "gut" talking, with no real specific knowledge.

    ymmv
  • Stanley Sufficool at Nov 5, 2010 at 4:57 am

    On Thu, Nov 4, 2010 at 7:44 PM, Richard Lynch wrote:
    On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote:
    On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch wrote:
    On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
    I realize as the guy who has to deal with the driver code and what it
    should do for people not following the advise below, it's probably
    preaching to the choir, but...

    Read the below comments this way:  Anybody dumb enough to rely on the
    kind of stuff you are asking about is already in Big Trouble (tm).
    I realize that non Zend types would have to be returned as a string
    representation.
    At the risk of repeating myself, even Zend types aren't going to match
    up -- The devil is in the details.  The range for an INT in the DB
    won't match the range for a Zend INT, for at least some databases,
    almost for sure.  I know 2s complement is 2s complement all over, but
    there has to be SOME DB out there that has a range +/- 1 compared to
    Zend INT.
    The hangups I am having is with large objects returned
    as streams in some drivers (but not dblib)
    I never really use large objects, as anything that large doesn't
    belong in the database in the first place... :-)

    Rule Of Thumb:
    If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
    doesn't belong in the DB.
    Put it in the custom highly-optimized specialized database engine
    commonly known as "the file system" where it belongs. :-)
    FWIW, large objects cannot be used in ORDER BY in MSSQL, and
    relational integrity is best achieved by having your data in a
    -relational- database.

    Think mugshots, digitized signatures, etc. I really do not wish to
    cycle through a record set to do a pass to delete the images on disk
    by filename reference and then run another SQL to delete the records.
    and inconsistent date/time
    string representations across drivers depending on server
    configuration files (freetds.conf).
    Ewww...  I generally use the DB date format feature to format dates in
    a consistent manner, rather than rely on whatever random date/time
    output the DB/driver chooses.
    And what ANSI SQL date conversion function would you suggest to
    outputa consistent string date/time? CAST(date as varchar)?
    Inconsistent at best across MSSQL, Oracle, PostgreSQL.
    Another BIG issue I am having when using strings with DBLIB is that
    they go through iconv, destroying binary values when translated to the
    server character set from the assumed latin1 PHP client character set.
    SQL Server for some reason allows characters to be stored in a
    varchar/text fields even though the character is not defined in the
    servers code page, whereas iconv pukes with an error.
    I'm not an i18n expert, but...

    Why is iconv being injected at this point?!
    Because all data on the wire from TDS is UTF16, including query strings.
    And why is PHP client library using latin1 for data that just isn't
    latin1?  That's just asking for problems...
    Theoretically I could ask for UTF8, but then I don't want to have to
    run utf8_decode/utf8_encode on all query strings, returned data, etc
    when the other drivers do not return unicode to PHP.
    I would expect any driver to just give me the raw data from the
    database, in the charset defined by the DB, and not to try to
    down-sample it to some other charset for me...

    Though I guess if you've told the PHP client to make it be 'latin1'
    the best it can do is trash it through iconv and you get what asked
    for...
    iconv is implemented in the freetds library outside of PHP. I guess I
    could copy all of the freetds library code into pdo_dblib to avoid
    iconv and external dependencies (making it a native driver)? It was a
    side thought in order to get pdo_dblib working on Windows.
    My only answer to that is to change your code to not ask for 'latin1'
    in the first place, when the data isn't latin1.  Change the PHP client
    charset to what it ought to be, and get the data you wanted, not some
    lossy down-sampled useless conversion of the data you wanted.

    I cannot comment on SQL Server behaviour with respect to the "servers
    code page" [sic], whatever that is, except to say that MySQL lets you
    define your charset on a table by table basis, and, I think, in recent
    versions, even on a field by field basis. OpenSource ftw, perhaps? :-)
    MSSQL allows per table and per column code pages in recent versions.
    As far as OpenSource DBMS', I support what my clients run, not what I
    want them to run. If I had my choice, I would be running PostgreSQL.
    It would be a wonderful development to have an RFC on the preferred
    string representation of various objects as returned by the driver so
    that when using ANSI SQL with PDO you can expect the same
    representation across all drivers.
    I'm all for documenting what SHOULD happen across all drivers, if
    a) the docs are sensible, and
    b) it can be implemented in all drivers

    I suspect that even a) would generate a TON of discussion on this list
    that would never be resolved, and that b) is simply not possible due
    to some really brain-dead drivers.

    But that's just my naive "gut" talking, with no real specific knowledge.

    ymmv

    --
    brain cancer update:
    http://richardlynch.blogspot.com/search/label/brain%20tumor
    Donate:
    https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

  • Lester Caine at Nov 5, 2010 at 8:28 am

    Stanley Sufficool wrote:
    Rule Of Thumb:
    If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
    doesn't belong in the DB.
    Put it in the custom highly-optimized specialized database engine
    commonly known as "the file system" where it belongs.:-)
    FWIW, large objects cannot be used in ORDER BY in MSSQL, and
    relational integrity is best achieved by having your data in a
    -relational- database.

    Think mugshots, digitized signatures, etc. I really do not wish to
    cycle through a record set to do a pass to delete the images on disk
    by filename reference and then run another SQL to delete the records.
    The first brick wall I hit when simply trying to use PDO was this one. On
    firebird big text fields are BLOB ( oracle is the same - CLOB ) and I simply
    want to read them as strings, but PDO 'optimizes' them as streams. Text search
    is best handled IN the database and the content needs to be there to search on
    or create indexes on. So while keeping all the binary content on my websites in
    the file system is acceptable, doing that with the text is simply wrong. ( Until
    perhaps a reach the point when an external text search option WOULD be more
    efficient ;) )

    Of cause the character set used for that data is then the next problem and has
    to be unicode internally since even little things like addresses need to be able
    to accept international users ... I don't have many Chinese/Japanese customers,
    but the address book can at least handle them :)

    In the database
    Rule one ... times are all UTC
    Rule two ... text is all unicode

    I still can't simply switch between the generic firebird driver and the PDO one
    in ADOdb so using PDO is academic at the moment. ADOdb does a GOOD job of
    managing the data types and I can switch between most db's with very little
    problem ... data wise ... it's always going to be the SQL that is the real
    problem, but with care that can be made reasonably generic as well as long as
    one bothers to think about that using PDO. Most 'conversions' simply break what
    was good cross db sql to 'simplify' things for PDO and then actually LOOSE
    access to most other db's :(

    --
    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//
    Firebird - http://www.firebirdsql.org/index.php
  • Stanley Sufficool at Nov 6, 2010 at 2:09 am

    On Fri, Nov 5, 2010 at 1:28 AM, Lester Caine wrote:
    Stanley Sufficool wrote:
    Rule Of Thumb:
    If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
    doesn't belong in the DB.
    Put it in the custom highly-optimized specialized database engine
    commonly known as "the file system" where it belongs.:-)
    FWIW, large objects cannot be used in ORDER BY in MSSQL, and
    relational integrity is best achieved by having your data in a
    -relational- database.

    Think mugshots, digitized signatures, etc. I really do not wish to
    cycle through a record set to do a pass to delete the images on disk
    by filename reference and then run another SQL to delete the records.
    The first brick wall I hit when simply trying to use PDO was this one. On
    firebird big text fields are BLOB ( oracle is the same - CLOB ) and I simply
    want to read them as strings, but PDO 'optimizes' them as streams. Text
    search is best handled IN the database and the content needs to be there to
    search on or create indexes on. So while keeping all the binary content on
    my websites in the file system is acceptable, doing that with the text is
    simply wrong. ( Until perhaps a reach the point when an external text search
    option WOULD be more efficient ;) )
    PDO "optimizes" as a stream because PHP may be limited in memory and a
    full fetch on a large object could be upwards of 2 GB. Regardless of
    preferences on filesystem vs database storage of LOBs, there are
    plenty of people using large objects in the database that are suitable
    for sequential stream access.
    Of cause the character set used for that data is then the next problem and
    has to be unicode internally since even little things like addresses need to
    be able to accept international users ... I don't have many Chinese/Japanese
    customers, but the address book can at least handle them :)

    In the database
    Rule one ... times are all UTC
    Rule two ... text is all unicode
    Rule three ... expect that rules 1 and 2 won't be followed by whoever
    designed the database before you and everything will be local specific
    and varchar.
    I still can't simply switch between the generic firebird driver and the PDO
    one in ADOdb so using PDO is academic at the moment. ADOdb does a GOOD job
    of managing the data types and I can switch between most db's with very
    little problem ... data wise ... it's always going to be the SQL that is the
    real problem, but with care that can be made reasonably generic as well as
    long as one bothers to think about that using PDO. Most 'conversions' simply
    break what was good cross db sql to 'simplify' things for PDO and then
    actually LOOSE access to most other db's :(

    --
    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//
    Firebird - http://www.firebirdsql.org/index.php

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Lester Caine at Nov 7, 2010 at 9:33 am

    Stanley Sufficool wrote:
    On Fri, Nov 5, 2010 at 1:28 AM, Lester Cainewrote:
    Stanley Sufficool wrote:
    Rule Of Thumb:
    If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
    doesn't belong in the DB.
    Put it in the custom highly-optimized specialized database engine
    commonly known as "the file system" where it belongs.:-)
    FWIW, large objects cannot be used in ORDER BY in MSSQL, and
    relational integrity is best achieved by having your data in a
    -relational- database.

    Think mugshots, digitized signatures, etc. I really do not wish to
    cycle through a record set to do a pass to delete the images on disk
    by filename reference and then run another SQL to delete the records.
    The first brick wall I hit when simply trying to use PDO was this one. On
    firebird big text fields are BLOB ( oracle is the same - CLOB ) and I simply
    want to read them as strings, but PDO 'optimizes' them as streams. Text
    search is best handled IN the database and the content needs to be there to
    search on or create indexes on. So while keeping all the binary content on
    my websites in the file system is acceptable, doing that with the text is
    simply wrong. ( Until perhaps a reach the point when an external text search
    option WOULD be more efficient ;) )
    PDO "optimizes" as a stream because PHP may be limited in memory and a
    full fetch on a large object could be upwards of 2 GB. Regardless of
    preferences on filesystem vs database storage of LOBs, there are
    plenty of people using large objects in the database that are suitable
    for sequential stream access.
    BUT at least having a switch to disable that action would be nice?
    BOTH actions are required SELECTIVELY by field if one database uses a large text
    field while the other uses a BLOB for the same size field. Current ports of
    projects TO PDO fall flat because Firebird and Oracle can't then access the text
    fields!
    Of cause the character set used for that data is then the next problem and
    has to be unicode internally since even little things like addresses need to
    be able to accept international users ... I don't have many Chinese/Japanese
    customers, but the address book can at least handle them :)

    In the database
    Rule one ... times are all UTC
    Rule two ... text is all unicode
    Rule three ... expect that rules 1 and 2 won't be followed by whoever
    designed the database before you and everything will be local specific
    and varchar.
    In that case the first step is to clean up the mess to sort the problems out
    that those bad practices have forced on the 'project'. As soon as I stripped all
    of the 'server time' crap from the original tikiwiki some time ago making a
    working cross timezone calendar was actually possible ... up until then it was
    always wrong for half of the year in some areas :)

    But porting a project CURRENTLY to PDO is not a sensible way to tidy things up :(

    --
    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//
    Firebird - http://www.firebirdsql.org/index.php
  • Stanley Sufficool at Nov 7, 2010 at 6:07 pm

    On Sun, Nov 7, 2010 at 2:33 AM, Lester Caine wrote:
    Stanley Sufficool wrote:
    On Fri, Nov 5, 2010 at 1:28 AM, Lester Cainewrote:
    Stanley Sufficool wrote:
    Rule Of Thumb:
    If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
    doesn't belong in the DB.
    Put it in the custom highly-optimized specialized database engine
    commonly known as "the file system" where it belongs.:-)
    FWIW, large objects cannot be used in ORDER BY in MSSQL, and
    relational integrity is best achieved by having your data in a
    -relational- database.

    Think mugshots, digitized signatures, etc. I really do not wish to
    cycle through a record set to do a pass to delete the images on disk
    by filename reference and then run another SQL to delete the records.
    The first brick wall I hit when simply trying to use PDO was this one. On
    firebird big text fields are BLOB ( oracle is the same - CLOB ) and I
    simply
    want to read them as strings, but PDO 'optimizes' them as streams. Text
    search is best handled IN the database and the content needs to be there
    to
    search on or create indexes on. So while keeping all the binary content
    on
    my websites in the file system is acceptable, doing that with the text is
    simply wrong. ( Until perhaps a reach the point when an external text
    search
    option WOULD be more efficient ;) )
    PDO "optimizes" as a stream because PHP may be limited in memory and a
    full fetch on a large object could be upwards of 2 GB. Regardless of
    preferences on filesystem vs database storage of LOBs, there are
    plenty of people using large objects in the database that are suitable
    for sequential stream access.
    BUT at least having a switch to disable that action would be nice?
    BOTH actions are required SELECTIVELY by field if one database uses a large
    text field while the other uses a BLOB for the same size field. Current
    ports of projects TO PDO fall flat because Firebird and Oracle can't then
    access the text fields!
    Seems simple to me, with the option to restrict to a specific memory footprint.
    http://php.net/manual/en/function.stream-get-contents.php
    Of cause the character set used for that data is then the next problem
    and
    has to be unicode internally since even little things like addresses need
    to
    be able to accept international users ... I don't have many
    Chinese/Japanese
    customers, but the address book can at least handle them :)

    In the database
    Rule one ... times are all UTC
    Rule two ... text is all unicode
    Rule three ... expect that rules 1 and 2 won't be followed by whoever
    designed the database before you and everything will be local specific
    and varchar.
    In that case the first step is to clean up the mess to sort the problems out
    that those bad practices have forced on the 'project'. As soon as I stripped
    all of the 'server time' crap from the original tikiwiki some time ago
    making a working cross timezone calendar was actually possible ... up until
    then it was always wrong for half of the year in some areas :)
    Unless there is an existing client application that uses the database
    in it's current state. The example here is a supplemental application
    that has to co-exist with another ancient application until all
    functionality has been replicated. In this case, the applications data
    only exists in one timezone and in one language/code page.
    But porting a project CURRENTLY to PDO is not a sensible way to tidy things
    up :(

    --
    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//
    Firebird - http://www.firebirdsql.org/index.php

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jonathan Bond-Caron at Nov 5, 2010 at 1:26 pm

    On Fri Nov 5 12:57 AM, Stanley Sufficool wrote:

    And why is PHP client library using latin1 for data that just isn't
    latin1?  That's just asking for problems...
    Theoretically I could ask for UTF8, but then I don't want to have to
    run utf8_decode/utf8_encode on all query strings, returned data, etc
    when the other drivers do not return unicode to PHP.
    Have a look at:
    https://open-mv.googlecode.com/svn/trunk/classes/database/drivers/

    I've solved most of these problems though not with PDO* drivers.

    I think you'll get the consistency you need for "2 interchangeable and have
    PHP/PDO applications run the same on Win32 and Linux" only minus the
    PDO/PDO_DBLIB part.

    In my opinion, PDO already does too much "abstraction magic", it would be
    great if PDO2? could expose somehow:

    static inline void fetch_value()

    so that in userland you could deal with custom data types and override how
    the data type bindings happen.

    That would be some much needed flexibility to actually create a "database
    abstraction" layer vs the pdo "data-access" layer.
    My only answer to that is to change your code to not ask for 'latin1'
    in the first place, when the data isn't latin1.  Change the PHP client
    charset to what it ought to be, and get the data you wanted, not
    some lossy down-sampled useless conversion of the data you wanted.

    I cannot comment on SQL Server behaviour with respect to the
    "servers code page" [sic], whatever that is, except to say that
    MySQL lets you define your charset on a table by table basis, and, I
    think, in recent
    versions, even on a field by field basis. OpenSource ftw, perhaps?
    :-
    )

    MSSQL allows per table and per column code pages in recent versions.
    As far as OpenSource DBMS', I support what my clients run, not what I
    want them to run. If I had my choice, I would be running PostgreSQL.
    Per column code pages / collation is actually part of SQL92 (postgresql
    doesn't support it, mysql, mssql,.. does)

    In windows, the SQL native driver will properly convert everything to UTF-8.
    In unix, FreeTDS should do the conversion correctly, have you run into
    problems? Is this related to the PDO driver?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 4, '10 at 1:52a
activeNov 7, '10 at 6:07p
posts13
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase