Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
In-Reply-To: <4742A299.2080107@oeri.ch>
References: <3E.97.05823.18DE1474@pb1.pair.com> <B1E5169E-6B18-437B-89DB-78EFD7D990F6@pooteeweet.org> <EE856B62-2992-4752-9B78-83287BF8BD5E@pooteeweet.org> <4742A299.2080107@oeri.ch>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <2BD36F6D-9A7C-40A6-A753-3E7C1979B8B6@pooteeweet.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Tue, 20 Nov 2007 10:30:57 +0100
To: Hans-Peter Oeri <hp@oeri.ch>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0, required 6)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] [PATCH] PDO::FETCH_2D
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 20.11.2007, at 10:02, Hans-Peter Oeri wrote:

>>> Not sure how real world useful this is. What I have seen more is a
>
> I often run into a situation like the following: We need a "framework
> like" class to change *joined* tables. The framework itself has no
> inherent knowledge about table fields, but (anyhow) loads table
> definitions. This functionality is useful for:
> a) duplicate field names in different tables (FETCH_NAMED does not  
> help)
> b) update tables, as - without any additional work - I have the fields
>    "by table"
>
> Access to fields w/o knowing their table is possible by combining
> FETCH_2D with FETCH_ASSOC or FETCH_NUM. As that creates references,
> changes to "table-less" fields are represented in the "table" fields
> automagically ;)
>
> I don't know how often, but in "my" real world, that's bloody useful.
> But at least much more useful than the existing  
> ATTR.FETCH_TABLE_NAMES...
>
> As for "empty string" index: In my proposal, you could:
> setAttribute( PDO::ATTR_2D_NULLBASE, '')
> Would your really like to *fix* it to that?
>

One of the problems people frequently run into with DBAL is that they  
will want to use the same connection/instance with different  
libraries in the same request. So every option brings with it the  
danger of making libs incompatible. However maybe we should try to  
find a solution for this independently, like some simple way to reuse  
a single connection across PDO instances. But this might cause issues  
with options that modify the connection. So maybe PDO needs some  
internal option decorator of sorts. Maybe lib authors should just  
work really hard to stick with defaults. In this case I would suggest  
making the empty string the default.

>> like I said ideally PDO would know about FKs and use those to  
>> build the
>> tree structure automagically.
>
> Any added *functionality* (defined by: PDO *knows*) must be sincerely
> discussed, I think. My proposal only adds a way to return fetched  
> data -
> PDO does not *know* anything more.

Right. I guess this feature would only make sense if this information  
would be easily available inside the result set meta data provided by  
the RDBMS, which is probably something that few if any RDBMS provide.  
Having some fancy syntax to define the result set structure is I  
guess something better left to an ORM or needs even lower level  
support like in C#. But form the point of view of an ORM it would not  
really need to be a simple API (as you would only have to implement  
this once) by which to tell PDO how to structure the results.

>> I would like to see:
>> 1) lazy connect
>> 2) driver independent DSN support
>

> But why lazy connects?

A lot of people like to create instances of everything at the very  
start of a request. But if you do heavy caching, you might not even  
need the database connection in the end. Of course with property  
overloading, one can already create the PDO instance on demand.  
However having an option for lazy connecting would allow people to  
more easily switch between the two modes. This should make it easier  
to deal with different libraries that expect a PDO instance to be  
passed to the constructor.

> As for DSN: Has anybody discussed including username/password into  
> the DSN?
> mysql:username:password@dbname=...

I think the username/password are separated for two reasons at this  
point:
1) Wez wanted to keep things as close as possible to how the  
underlying C libraries worked
2) Some people prefer the "location" be separated form the user  
credentials for security reasons

That being said I think it would be a good idea to support the  
PEAR::DB DSN format (which does include the username/password).

regards,
Lukas