Generic Database Interface

[Amy Stephen]

Is there any interest in pursuing a very simple interface for database interaction?

Here's a proposed Interface for consideration:

https://gist.github.com/AmyStephen/5475201

[Kinn Julião]

IMHO, we do have PDO; it does its job very well.
Looking to this gist:
- "my thinking is that the Interface needs to be lower level than any ORM handling or SQL Building tool."
More than PDO?

2013/4/27 Amy Stephen <amyst...@gmail.com>

Is there any interest in pursuing a very simple interface for database interaction?

Here's a proposed Interface for consideration:

https://gist.github.com/AmyStephen/5475201

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/aDIqcCwIkEkJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

---------------------------------------------------------

             Kinn Coelho Julião

            

                 kinncj.com.br
               About.me/kinncj

---------------------------------------------------------

[Amy Stephen]

Left you a message on the gist, too. I have no experience with PDO. It appears to be database-specific, rather than an abstracted layer and it says it is still experimental. Having said that, I agree that if PHP has a solution, that seems the way to go. I'll take time to review. Thanks for sharing!

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/U2-gctko4iI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Kinn Julião]

Left you a message on the gist, too.

-- Yeap! I saw!

I have no experience with PDO.

-- It is time to have, prepared statements FTW !

It appears to be database-specific, rather than an abstracted layer

-- No, it is not :-) http://www.slideshare.net/wezfurlong/php-data-objects (Sorry for the old presentation, but it still working!)

and it says it is still experimental.

-- Nops :-D

 Having said that, I agree that if PHP has a solution, that seems the way to go. I'll take time to review. Thanks for sharing!

-- Your welcome! Marco said something interesting in the Gist. Just a tip: s/kinncg/kinncj/g

2013/4/27 Amy Stephen <amyst...@gmail.com>

[Larry Garfield]

PDO by design abstracts most, but sadly not all, off the PHP API for various databases. Where it doesn't, it usually relates to LOB/BLOB handling in certain databases, and that oversight is annoying. It does nothing for abstracting differences in SQL dialect, however, save for prepared statements, and that's where the really ugly work has to happen. That's not something that can be standardized at the interface level/FIG level.

I have no idea why PDO would be marked experimental. It's several years old, quite stable, and in widespread use as the recommended SQL tool. Sounds like some docs need updating.

--Larry Garfield

[Amy Stephen]

Larry - I'm recommending *not* standardizing at the SQL level, but rather one level below. at the base interaction with the database, given prepared SQL. Most member projects have their own database packages and this would enable a first step towards interoperability at that level.

Regarding the PDO point -- I think this get right into what is the scope of FIG.

My understanding was that FIG's goal was to build interoperability into code that member projects already have available. Using Interfaces as a vehicle, projects could build in handlers that allow "swapping out" their solution with the solution of another project that follows the specs, and therefore build in interoperability.

The question as to what is the best solution or better approach is an answer that would likely evolve once the packages are interchangeable but I don't know that it's relevant initially as the goal is to use what projects have -- so that code can be used together.

This is an important distinction and one that I believe might be stalling progress for the group. Maybe it's my understanding that is wrong, or maybe the group's purpose is still evolving, but I think it would be good to see if that can be clarified. I know you did a survey of that question but I am not certain anything directional came from that work.

Thanks!

[Larry Garfield]

I think you're missing my point. PDO already covers about 90% of what a common DB layer like you suggest would be able to reasonably standardize. I don't see a great deal of value in adding more on top of that, since there is very little that could be done without getting into the messy implementation details that we don't want to get into anyway. That other 10% would be better handled with improvements to PDO itself. (E.g., LOB handling.)

DB abstraction layers are the oldest API to have such standardization in PHP, and have a long pedigree. PDO is the de facto standard for that already. I don't see a need for us to reinvent that wheel.

[Drak]

Amy, look at Doctrine DBAL. 

Drak

--

[Amy Stephen]

Larry -

Ok, question for you, then. Let's take Drupal's database package, as an example. It appears to heavily utilize PDO but there still is a lot of valuable code (~ 610kb, 85 files) written implementing PHP's PDO approach in such a way that an application can better utilize those capabilities. Currently, that code is useful only within the Drupal application. What would it take to break it off and offer it separately so that the benefit could extend to other applications? 

I'm not looking at these different implementations with an eye towards "what is the best approach." I look at the enormous amount of code we have all created and think "how can we isolate function into 'black box utilities and create a plug and play environment?" At that point, quality metrics start to have real meaning because it is *possible* to exchange one for the other.

Starting Wednesday, I'll have some time to play around with this it and I'm curious if I would be able to create a Drupal database handler for this interface if I could use it to switch to the Drupal package -- and not change any of my application code. If so, would that be a useful exercise towards interoperability for you? 

Thanks Larry.

[Amy Stephen]

Drak - I will do so (later this week). When I do, are there specific
points I should be looking for?

Thanks!

> You received this message because you are subscribed to a topic in the

> Google Groups "PHP Framework Interoperability Group" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/U2-gctko4iI/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to

> php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.

[Drak]

Well, my point is it's already a complete cross DB abstraction. No need for a PSR.

Drak

[Amy Stephen]

Briefly looked at other approaches from members:

Doctrine: Connection has prepare, query, quote, exec, lastInsertId, beginTransaction, commit, rollBack, errorCode, ErrorInfo

zf2  Database Adapters. The ConnectionInterface has connect, isConnected, disconnect, beginTransaction, commit, rollback, execute, getLastGenerateValue

Laravel The ConnectionInterface has selectOne, select, insert, update, delete, statement, transaction

Lithium Abstract handler for databases encoding, error, execute, insertId, connect, disconnect, name (escaping), value (escaping), create, read, queryExport, update, delete,

Looks like these environments are getting close, at least, to interoperability, assuming low coupling with the application, itself.

[Peter Cowburn]

On 28 April 2013 05:55, Larry Garfield <la...@garfieldtech.com> wrote:

I have no idea why PDO would be marked experimental. It's several years old, quite stable, and in widespread use as the recommended SQL tool. Sounds like some docs need updating.

A couple of the PDO drivers are still considered experimental (you'll see a big-red-warning-box in the docs for those drivers), as well as a couple of methods on an otherwise not-experimental driver (SQLite); but not the PDO extension itself. I don't see anywhere in the docs stating that PDO as a whole is experimental, and the few experimental parts are clearly labelled as such.  

[Amy Stephen]

Peter - that very likely is what I saw, thanks for that. I should have shared the link.

--

[Paul Jones]

On Apr 28, 2013, at 10:51 AM, Amy Stephen wrote:

> Briefly looked at other approaches from members:
>
> Doctrine: Connection has prepare, query, quote, exec, lastInsertId, beginTransaction, commit, rollBack, errorCode, ErrorInfo
>
> zf2 Database Adapters. The ConnectionInterface has connect, isConnected, disconnect, beginTransaction, commit, rollback, execute, getLastGenerateValue
>
> Laravel The ConnectionInterface has selectOne, select, insert, update, delete, statement, transaction
>
> Lithium Abstract handler for databases encoding, error, execute, insertId, connect, disconnect, name (escaping), value (escaping), create, read, queryExport, update, delete,
>
> Looks like these environments are getting close, at least, to interoperability, assuming low coupling with the application, itself.

And of course Aura:

<https://github.com/auraphp/Aura.Sql/blob/develop/src/Aura/Sql/Connection/AbstractConnection.php>

connect/disconnect, query, beginTransaction/commit/rollback, fetch(All|Assoc|Col|Value|Pairs|One), quote(|Into|Multi|Name|NamesIn), insert/update/delete, new(Select|Insert|Update|Delete), fetchTable(List|Cols).


-- pmj

[Amy Stephen]

Thank you, Paul. Aura is on my list for this week. More and more impressed with that code base. Looks like someone codes with a broom, it's so clean.

[Larry Garfield]

Ah, near and dear to my heart. ;-)  (I wrote or at least architected most of those 610 KB.)

We've discussed breaking the DB component out to a stand-alone library.  Currently you can use the MySQL implementation sans-Drupal by commenting out about 2 lines (function calls).  It's *almost* Drupal agnostic already.  The problem is that removing the parts that are in a way that would let Drupal easy re-add them is, unfortunately, not a small task.  (That's largely a limitation of PHP's OO capabilities, frankly.)  And everyone who would be able to do so has been very busy on other parts of Drupal for this entire dev cycle. 

The other big limitation is that our connection object extends PDO rather than wrapping it.  That was, in hindsight, a mistake IMO, but again, changing it now would be a not-small amount of work.  That's unfortunate, because frankly I think the overall design is damned good aside from those issues.

I don't know if you'd be able to wrap the Drupal DB system into this interface.  Maybe, if you comment out the 2-3 Drupal-specific function calls.  If you want to give it a try feel free to ping me in IRC if you need advise and I'll see what I can do to help. :-)

That said...  If the goal is, like PSR-3, to offer a "hey random library, you can work really easily with all of these frameworks if you talk to the DB using this interface", then "using this raw PDO object" is already most of the way there.  Where it isn't... is mostly PDO design flaws that are really hard to fix in user-space with just interfaces.  The LOB handling that I mentioned, for instance, is why Drupal requires the use of query builders for DDL, which is way outside the scope of what we can standardize via interfaces.  Standardizing "get me the quote character you use" is one thing, but if you're using prepared statements you rarely need that.

It's not that I don't see value in having a common database interface.  It's that the places we don't already have one I don't believe can be resolved in user-space, but would need to be addressed as patches to PDO itself (which it desperately, desperately needs).

--Larry Garfield

[Amy Stephen]

Thanks, Larry, for your response.

Couple of quick points (it's past 1 and big day tomorrow) - first, yes, I think it is important to keep the SQL layer out of the first pass. It is a higher level layer.

I realize that for many/some projects, there might be uncoupling would be needed between the low-level database interaction and the SQL layer - but it makes good sense to treat those as very separate entities. The primary reason is -- the SQL tends to be much more deeply embedded within an application where most projects have evolved their code base to where the database interaction is very nicely isolated.

With that low-level database interaction tackled, then it would be much easier to think about the next step (or to decide that's where sharing ends, due to the coupling of SQL within the primary application code base.)

There is benefit to being able to interchange databases. That should make it easier (over time) for  projects with less advanced database packages to make a quick low level switch to something much more robust without having to rewrite any application code. That puts those projects into a good position since a roadmap to ORM can emerge as time allows.

Second, I am definitely interested in the uncoupling/packaging of the Drupal database. It might be a big bite for a first go at contributing in Drupal but even if it didn't work out, I'd still learn a lot about your database engine, so that's a big win. Hoping this week to finish a major project and free my time up a bit for more exploration. Will ping you in the IRC later.

[Phil Sturgeon]

I think this is the sort of conversation that gives people the impression the FIG is trying to build a mega-framework-of-doom.

If this is not going to get into SQL dialects and just handle connections as you say then this really feels like a job for PDO. Adding anything else in between is just going to introduce an extra dependency for the sake of it for the sake of handling some 10% edge-cases that PDO is not too good at doing itself.

For the record, Laravel 4 uses doctrine/common and doctrine/dbal already. There are a few bits of "connection and config" management code around, and they all work rather nicely and while they are relatively similar I don't see much benefit in forcing a shared interface on them. They can all return a PDO object for me to work with in my application, which is abstracted enough already.

I'm sure you could draw similarities to the idea of PSR-3, but not quite, as PHP didn't have a "relatively good" logger abstraction layer to begin with.

[Daniel Ribeiro]

2013/4/30 Phil Sturgeon <em...@philsturgeon.co.uk>

I think this is the sort of conversation that gives people the impression the FIG is trying to build a mega-framework-of-doom.

That's exactly the impression I have right now.

2013/4/30 Phil Sturgeon <em...@philsturgeon.co.uk>

I'm sure you could draw similarities to the idea of PSR-3, but not quite, as PHP didn't have a "relatively good" logger abstraction layer to begin with.

And even so I'm convinced PSR-3 was a huge waste of time.

This group is getting so boring...

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

2013/4/30 Phil Sturgeon <em...@philsturgeon.co.uk>

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/8KvGVKmsM7IJ.

[Amy Stephen]

Lots of good work out there in the database area:

• Each of these packages, with the exception of one, have Interfaces that position for use in other projects.
• Each of these packages, with the exception of two, are already offered on Packagist.
  
• Each of these packages *heavily* rely upon PDO.
  
• None of these packages are small, there is considerable code, even with PDO's advancements.

The challenge to interoperability is that none of these packages have exactly the same Interface.

That means application code changes are required to use the ZF2 database package instead of the Aura database package, and visa versa.

The good thing is that in reviewing the interfaces, it's clear the differences are minor and reconcilable.

A common interface, implemented using an adapter pattern and database handlers makes these packages interoperable from an application standpoint. To use another package that is more performant, or required by my client, is simple with that type of architecture -- I just add the package to composer.json and update.  No other work is needed.

That's interoperability! And, yes, it would be just like the accomplishments of the logger interface. =)

Regarding the split in architecture layers between base level database interaction and SQL generation, listen to Matthew O'Phinney's comments that are mentioned in how the ZF2 database package is architected to be used at that low level, in addition to providing SQL or ORM support. http://devzone.zend.com/2106/interview-with-matthew-weier-ophinney/ It's a side discussion in a bigger interview facilitated by Cal Evans, but the focus is on smaller units, interoperability, standardization, and worth the time for all of us learning those concepts to consider.

Thanks for your comments.

[Evert Pot]

On Apr 30, 2013, at 6:51 PM, Amy Stephen <amyst...@gmail.com> wrote:

> Lots of good work out there in the database area:
> • Each of these packages, with the exception of one, have Interfaces that position for use in other projects.
> • Each of these packages, with the exception of two, are already offered on Packagist.
> • Each of these packages *heavily* rely upon PDO.
> • None of these packages are small, there is considerable code, even with PDO's advancements.
> The challenge to interoperability is that none of these packages have exactly the same Interface.
>
> That means application code changes are required to use the ZF2 database package instead of the Aura database package, and visa versa.
>
> The good thing is that in reviewing the interfaces, it's clear the differences are minor and reconcilable.
>
> A common interface, implemented using an adapter pattern and database handlers makes these packages interoperable from an application standpoint. To use another package that is more performant, or required by my client, is simple with that type of architecture -- I just add the package to composer.json and update. No other work is needed.
>
> That's interoperability! And, yes, it would be just like the accomplishments of the logger interface. =)

We need to avoid creating another ORM. Propel and Doctrine fill that space, and they do it quite well. Not to mention that these projects have been at it for years. It will be very hard to create something that's both minimal, and useful and actually picked up by anyone.

The reason existing database layers are not identical, is because they have different design goals and ideas how this should be approached. If these ideas were identical, there would not be a real need for alternatives.

I also feel that any PSR should be simple and to the point. Creating something that abstracts SQL syntax by creating a new syntax (such as doctrine's DQL) or through an OOP interface is a massive project, and would in the end just create another competitor. I doubt that ay member projects would be interested in pursuing such a massive venture, I have, at the very least, not yet heard positive feedback of that nature.

So given that, and assuming I'm right, what would be a good choice for a common interface for database access? In my mind this would just be the absolute basics (prepare, query, quote) and we have a way to do that: PDO.

So any projects that don't want to depend on 1 ORM, can allow consumers to inject an instance of PDO. All you really need then is a way for the existing ORM's to get a hold of the underlying PDO object, and you've basically solved your problem.

So yea, I believe that this should not be solved as a PSR, it should be solved as an external package (Doctrine, Propel or something new), or not at all (and just stick to PDO).

But, if you don't buy my argument... I would say... rather than thinking about this on a conceptual level, try thinking about what it would actually take to write this.. Write the interface, do a couple of implementations and see if you can come up with something that's both useful and simple.

At the very least that will give us something realistic to debate for it's usefulness and whether projects would be interested in picking it up.

Evert

[Amy Stephen]

Evert -

It's hard to say I don't buy your argument, the problem is most of your argument isn't related to proposal. In fact, you are repeating much of what I said. The proposal is not about the ORM portion. =)

On Tue, Apr 30, 2013 at 1:13 PM, Evert Pot <ever...@gmail.com> wrote:

But, if you don't buy my argument... I would say... rather than thinking about this on a conceptual level, try thinking about what it would actually take to write this..

 

Write the interface,

I linked to it in my first post. =)

 

do a couple of implementations

I have already created an adapter and the first handler - for the Joomla database package.

As I mentioned a few times, I am creating handlers for other databases, too.

 

and see if you can come up with something that's both useful and simple.

It is useful for my needs. If it is useful for others, cool. 
 

At the very least that will give us something realistic to debate for it's usefulness and whether projects would be interested in picking it up.

I agree and that is exactly what I am doing. Sharing code if others are interested.

For me, the bottom line is I need it. I am not concerned about convincing anyone else but I do believe it's appropriate to respond to the discussion I started.

Thanks Evert!

 

[Evert Pot]

On Apr 30, 2013, at 7:57 PM, Amy Stephen <amyst...@gmail.com> wrote:

> Evert -
>
> It's hard to say I don't buy your argument, the problem is most of your argument isn't related to proposal. In fact, you are repeating much of what I said. The proposal is not about the ORM portion. =)

Right! Sorry, I completely missed those parts, so much of my argument is gone.
What's left of my argument is then indeed : what's wrong with relying on PDO for this purpose?

As long as implementors provide a way for users to get access to the underlying PDO object, this should solve your use-case, no?

Evert

[Amy Stephen]

Thanks Evert, appreciate it. It's hard to discuss things in a focused way on the Internet where confusion abounds!

I'm going to kind of turn your question around on you and ask "Why are so many projects creating packages that based on PDO?"

Using Aura as an example, since it's very clean, uncoupled code, it's basically a wrapper around existing PDO functionality. It appears to put in place a missing layer that allows the application to interact with the database, independent of the handler (be it mysql, sqllite, or postgresql)

As PHP is evolving, it is very true that less code is needed by our frameworks and applications. But, that evolution does take time and during that transition I suppose we will continue to see some packages that are little more than wrapping and slightly improving, simplifying what PHP offers natively. The same question comes up for Filesystem packages, Field Handling, like filtering and validating and escaping, and so on.

I believe there is still a need for a limited code set for database handling at this time. But, I will be learning as I bring in other handlers and I am known to change my mind due to my experience.

Appreciate your comments, always.

Evert





--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/U2-gctko4iI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Kinn Julião]

I think things are going bad here... since few months ago.

I'm not a voting member, but things like this makes me really upset.

We don't really need an interface to do what PDO does...
You said that the proposal is more low level... like PDO is!

To make things easy to detach and attach, the API should be almost the same... so, we are not talking about low level anymore, we are talking about API, about the exposed methods which the application will gonna use...
Internally, every dbal/orm/whatever that uses PDO will use "execute/query/etc", as the "low level" interface proposal... but not necessarily the exposed API will have an "execute" method and THIS is what do you need to make this "I just add the package to composer.json and update.  No other work is needed." work... since almost of projects here used PDO as it "low level awesome what ever" we don't need to waste time in a "low level more awesome than pdo" interface.

PDO is what everybody here needs instead of an interface to do that.

Now, talking about the exposed API...things don't need to be easily attached/detached... You cannot use a MegaBlock with a LEGO block... it is the same idea!

We don't need to have 2 or more ORMs doing the same thing in the same way with the same API! Because in this way there is no need to have 2 or more ORMs!
Things should work a little bit different... it is like lifestyle.. I like to use Doctrine because I'm happy with its api and how it works as we have happy people working with propel for the same reason!

For me, makes no sense to have this proposal.
 

2013/4/30 Amy Stephen <amyst...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Evert Pot]

On Apr 30, 2013, at 8:22 PM, Amy Stephen <amyst...@gmail.com> wrote:

> Thanks Evert, appreciate it. It's hard to discuss things in a focused way on the Internet where confusion abounds!
>
> I'm going to kind of turn your question around on you and ask "Why are so many projects creating packages that based on PDO?"

Well, the reason PDO is popular, is exactly the same as the reason you would like this PSR. It's a unified interface for many databases :)


So why a PSR when we have something:

* that addresses the same use-case
* Is actually more complete than your proposal (prepared statements are MUST-have)
* Lots of people are already using
* Is built into PHP and shipped with almost every distribution

Of course, not everyone uses PDO. Some people use the driver-specific libraries. A good reason to do so, is because a driver-specific extension may implement a feature that PDO doesn't (asynchronous queries in the mysqlnd library for instance).

But your proposal does not fix this, as it suffers from the same limitations that PDO has. The people that now choose to use a driver-extension over PDO, are unlikely to use this PSR.

That is, unless I'm missing some benefit to have a userland-version of PDO that I don't see right now :)

Evert

[Evert Pot]

On Apr 30, 2013, at 8:28 PM, Kinn Julião <kin...@gmail.com> wrote:

> I think things are going bad here... since few months ago.
>
> I'm not a voting member, but things like this makes me really upset.

If you're getting upset about discussion on this list... you're in for a tough future :)

Evert

[Amy Stephen]

Kinn -

I don't want you to be unhappy, so, I am very sorry to have played a part in creating any negative feelings in you.

Again, I do agree with comments made about the power and capabilities that are offered in the ORM tools available today. In fact, I have repeatedly tried to clarify that I see those tools as a layer higher than the interface I am working on for my needs.

Maybe it's not so much a right or wrong, but rather just a different approach? In some cases, it's not necessary to have the power that something like Doctrine offers. And, for some developers, it might be helpful to offer an easy "point of entry" where they can begin building skills with Doctrine using basic database methods, before they start to tackle concepts like Domains and Entities and really start to data modeling.

Some applications are very simple and they can benefit from a nicely wrapped PDO implementation like Aura's https://github.com/auraphp/Aura.Sql

But, I am happy to accept your point of view and learn from you. Your comments add to my eagerness to get involved with Doctrine.

Thank you very much for sharing your perspective and helping to educate me.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/U2-gctko4iI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

[Amy Stephen]

Evert - you could be right. As you suggested, I need to continue with creating some handlers and see where it leads. Thanks much for your time.

[Drak]

On 30 April 2013 18:19, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

I think this is the sort of conversation that gives people the impression the FIG is trying to build a mega-framework-of-doom.

Yeah. I'm not very convinced about the merits either. PDO covers this quite well. It's already part of the PHP core and I dont see any reason to go beyond. In the same way that if a PSR0 autoloader was part of PHP core, we'd simply not need a PSR for it. PDO abstract is enough.

Regards,

Drak

[Lukas Kahwe Smith]

PDO has deficiencies (mostly because it was build in the direct opposite way of "by committee", ie. one person just deciding .. neither approach leads to perfection on the first try), which is why there was discussion about PDO2 .. those discussions however ended up in a flame war about legal questions around introducing a CLA. I think there is some design concepts in either the PECL git or the wiki or both.

Furthermore I am of the opinion that core is the wrong place to design OO API's .. especially when dealing with the complex mine-field like RDBMS/SQL abstraction.

That being said, imho I feel we have lower hanging fruits than DB abstraction with which we are having enough trouble as it is with thing like HTTP and Cache. However if enough people feel passionately about this topic then I think given the size of this it should deserve a list of its own to iron out things and it would need to have buy in from key authors of popular DB abstraction libraries.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Drak]

On 1 May 2013 11:23, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:

That being said, imho I feel we have lower hanging fruits than DB abstraction with which we are having enough trouble as it is with thing like HTTP and Cache. However if enough people feel passionately about this topic then I think given the size of this it should deserve a list of its own to iron out things and it would need to have buy in from key authors of popular DB abstraction libraries.

And that would be as successful as the CS mailing list ;-)

Regards.

Drak 

[Amy Stephen]

Thanks for sharing those comments on the background with PDO. Interesting, we cannot help but leave our human print on all technology.

It certainly does not appear that there is a lot of (any!) interest in a DB interface. If it is okay, what I will do then is simply leave a link for the package I linked to above when I have finished exploring a few more handlers. That way, if anyone wants to see what an Interface like this might offer, they can do so. Maybe in time, the idea might have merit, maybe not.

I definitely agree getting the HTTP and Cache recommendations moving is priority.

Thanks to everyone for your time and feedback.