[wp-hackers] Adding wp-includes/class folder

[Stephane Daury]

re: db abstraction:

If coupled with a PHP5 (well, 5.1+) port effort, I'd recommend the  
built-in PDO (http://ca.php.net/pdo).
I'm down to the point where I even use it in environments where I  
only have to support a single RDBMS, for the "prepare" method and such.

In the backward compatibility context, I've always had very good  
experiences with ADOdb (http://adodb.sourceforge.net/) which is  
insanely flexible and powerful, and has the fantastic advantage of  
actually dealing with most of the SQL capabilities differences for  
you. It even has its own query caching engine, when not natively  
supported by the DB.
I've been using it for 5-6 years now (a lot before, less since PDO),  
and although it has lost steam when PDO came out (about a year or  
less), development picked up again and the latest version is from May  
2007.
I went the PEAR way in the past, but it's not always easy to install  
PEAR modules in some hosting plans, and the whole PEAR DB to MDB2  
switch only made things worse for me once or twice.

The largest OSS project I've ever released (netjuke) was "DB- 
independent". It ran on MySQL, PostgreSQL, SQLite, Sybase, MSSQL, and  
others (even Access).
What I learned from that project is that DB abstraction doesn't mean  
you have to support them all at once, and only tweaks are usually  
required to support a new DB.
One advantage of WP being so attentive to backward compatibility is  
that its SQL base has been kept away from advanced features (views,  
transactions, stored procedures, etc) which is usually where things  
get awry. Other features such as auto-incremented IDs (vs. sequences)  
are usually pretty widely supported by now.

Stephane



On Aug 31, 2007, at 12:24, jacobsantos at branson.com wrote:

> Makes sense. When I submit the patch for XMLRPC, I'll update it to  
> exclude the changes I made to IXR.
>
> I think at this moment the least amount of restructuring as  
> possible is needed. So while I also think the Factory model would  
> be nice in several areas. If the devs would accept a simplified  
> version, it would be easier to get on board with the more complex  
> restructuring.
>
> I think the Database Access Abstraction Layer is another good  
> candidate for the factory model, even with it technically being an  
> external library. However, this implies more work and I've yet to  
> figure out a good way to think about a easy way to get around the  
> differences of SQL.
>
> Ideas
>
> 1. Have a object for each SQL platform supported with only SQL.  
> I've decided against this.
> 2. Have functions that returns just the SQL for that API. Just as  
> bad as 1.
> 3. XML? Eh.
>
> Probably just keep it as it is for the SQL, but allow for the query  
> layer to be updated.
>
> Jacob Santos
>
> Stephane Daury wrote:
>>
>> 3rd party libs are always an issue in this kind of restructuration.
>>
>> For this reason, I always make a habit of having all 3rd party  
>> dependencies in their own specific subtree so that there is a  
>> clear distinction and do not feel compelled to apply my convention  
>> to these pieces. Then I have a simple wrapper implementing/ 
>> including the 3rd party software, which itself respects the  
>> convention.
>>
>> A side advantage is that the wrapper allows me (very often) to  
>> switch the said 3rd party software to another provider when a  
>> better solution comes along or allow library choices when  
>> available (such as different caching mechanisms, locale support  
>> systems, etc).
>>
>> I know it sounds heavy, but it pays off in flexibility in the long  
>> term.
>>
>> Stephane
>>
>>
>>
>> On Aug 31, 2007, at 10:02, Kimmo Suominen wrote:
>>
>>> On Fri, Aug 31, 2007 at 02:13:41PM +0100, Peter Westwood wrote:
>>>>
>>>> For things like IXR / POP3 support / PHPMailer - splitting the  
>>>> classes
>>>> out is a really bad plan IMHO - they are external libraries that we
>>>> include and we need an easy way of diffing between our version  
>>>> (with
>>>> some patches) and the upstream version so as to make it easy to  
>>>> pull in
>>>> updates.
>>>
>>> Similarly renames and code shuffling between files easily creates
>>> a lot of extra work, as svn isn't smart enough to merge changes
>>> from changed files into the new file (let alone the new location
>>> of a file fragment, e.g. when a function is moved to another file).
>>>
>>> Such changes shouldn't be made lightly, in my very humble opinion.
>>>
>>> Best regards,
>>> + Kimmo
>>>
>>> P.S. Any svk gurus around willing to tell me what I'm doing wrong?
>>> -- 
>>> <A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
>>>
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>
>>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers