Re: [PDO] wiki clean up and potential in person meeting

On Dec 29, 2009, at 1:26 PM, Lester Caine wrote:

> Wez - the current discussion is about what NEEDS DOING ... and it is  
> the DATA abstraction that is not consistent - which is why  
> applications that have been converted to PDO are now hitting the  
> brick wall since most 'conversions' are only MySQL compliant.

I'm aware that the discussion is about what is needed, but I was  
pointing out that you're focused on the non-use-case of database  
abstraction, and moaning about firebird yet again.

> Adding posgresql is not difficult, but is a lot of additional hand  
> coding, duplicating large blocks of code that work with Postgresql  
> rather than MySQL.

Again, database abstraction.

> The main question that was asked is if PDO can replace the generic  
> drivers. Currently the answer is no, and so that fact should be made  
> clear. PDO is NOT providing even data abstraction.

I think the question of replacing the traditional drivers should be re- 
phrased as "what capabilities are needed to replace the 90% use  
case".  I think you'll find that PDO exceeds this goal except in some  
relative corner cases.  If we have a list of deficiencies materialized  
(which likely requires a list of use-cases materialized as a pre- 
requisite), it is that much easier to see what needs to be done.

> Simply a crude set of compatible functions that can't CURRENTLY be  
> combined with the more advanced transaction and other features of  
> the generic drivers.

Again, database abstraction.  Remember that the old style drivers  
never promised this feature either.

> we have several projects each writing their own 'compatibility'  
> layer on top of PDO - which is rather a waste of resources!  
> Especially when it only results in compatibility with a couple of  
> databases.

Different layers have different goals; yes it would be great if there  
was minimal effort needed to switch between databases, but it is not  
possible to solve every problem in the data access layer without  
making it hugely complex.

Given limited developer resources, it seems prudent to focus on the  
battles that can be won (closing the perceived feature gap with the  
old drivers) rather than questing for a holy grail.

--Wez.