Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50105
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=haPq4fg64xfS0khHoj/eIXxJnjXSZtsq3dI+YW46CESawmKTIhnFbGQERhuMghOMXX
         IlJM+V+kbRdNgSybRMJfw7wzrhW6pCEyqzK3qVF0vLLcz+TN2f5Mb6pK5JaiM4WxFK2n
         OdCS7TIAXPMUAqhLn9l1D3MHRq+se5XVMm7hU=
MIME-Version: 1.0
In-Reply-To: <ec385a4a428945f591e5748d6af8053f.squirrel@www.l-i-e.com>
References: <AANLkTikKybPrGWLj3rT3ydvf8H0N6O6mHP=MEmnL58Yh@mail.gmail.com>
	<24c7fdf08ac80c097306908d0c4b5512.squirrel@www.l-i-e.com>
	<AANLkTikifSrLNFu+Ui6ZtdkyOtmgbEF60=J-0UhRXEnJ@mail.gmail.com>
	<ec385a4a428945f591e5748d6af8053f.squirrel@www.l-i-e.com>
Date: Thu, 4 Nov 2010 21:57:40 -0700
Message-ID: <AANLkTinFk6TC5OmUHExE7rwLKFh6mo_DWpbwP6dc2Pjw@mail.gmail.com>
To: Richard Lynch <ceo@l-i-e.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PDO_DBLIB Native PHP Type binding
From: ssufficool@gmail.com (Stanley Sufficool)

On Thu, Nov 4, 2010 at 7:44 PM, Richard Lynch <ceo@l-i-e.com> wrote:
> On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote:
>> On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch <ceo@l-i-e.com> 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: =A0Anybody 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. =A0The range for an INT in the DB
> won't match the range for a Zend INT, for at least some databases,
> almost for sure. =A0I 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... =A0I 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? =A0That'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. =A0Change 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=3D_s-xclick&hosted_button_id=3D=
FS9NLTNEEKWBE
>
>
>