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
