?

Log in

No account? Create an account
Lord Yupa

February 2010

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28      
Powered by LiveJournal.com
Danger Mouse

Bleh.

Available documentation for PHP's "PEAR" project blows serious chunks.

They're sitting on what appears to be a reasonably decent database independent class (analogous to Perl's DBI class), and it's a royal pain to use because I can't find crap for information on it. Do they realize that developers (read, ME) want to use this, and would like to use this, assuming they could figure out how?

In other news, my porting of WikkiTikkiTavi, a really neat wiki to make use of PostgreSQL is stalling. The database abstraction layer designed into 'Tavi is not quite up to handling PostgreSQL (designed for MySQL), and the work it would take to get it directly working with Postgres is about the same as it would require to port it over to using the PEAR DB class.

Yeah, so now I just need to get the motivation to do that. Oh, and the knowledge.

Comments

PHP's lack of a database abstraction layer is one of the big reasons I started to dislike it - having a totally different API for ''every'' database really got on my nerves.

I'd say DoTheSimplestThingThatCouldPossiblyWork - just port it to PostreSQL. If necessary, RefactorMercilessly so that all the database code gets isolated in one little module. But why write with pear if you don't need to? YouArentGonnaNeedIt.

Now you've got those concepts in mind, ask yourself: Why do I need a relational database? OurPlace (850 pages) uses in-memory objects and serialization, and won't need rewriting to use more efficient storage for quite a while. According to WardsWiki, the average page size is about 1k, which means 1Meg of RAM per 1024 pages. Big whoopie. :) (meanwhile since everything's in memory, searches and retrievals are incredibly fast).

WardsWiki (18,000 pages) uses Berkeley DB, although it does use an external index for the full-text searches.
PHP's lack of a database abstraction layer is one of the big reasons I started to dislike it - having a totally different API for ''every'' database really got on my nerves.
I agree. Although, I think it's even worse that they have one, which has been included since PHP 4.0 (in some form or another), but that they haven't documented, so no one knows about it.
I'd say DoTheSimplestThingThatCouldPossiblyWork - just port it to PostreSQL. If necessary, RefactorMercilessly so that all the database code gets isolated in one little module. But why write with pear if you don't need to? YouArentGonnaNeedIt.
Well, as things stand right now, WikkiTikkiTavi has a single module where all the database code is abstracted to. The problem is that the abstraction layer was written by someone who only knew MySQL, so it doesn't take into account that other databases might want a different type of information to execute certain functions.

So, as things stand right now, I'm going to have to go through and change every single place that calls a function from the database abstraction class in Tavi, just to port it to Postgres. Additionally, if I do a straight port to Postgres, then I end up forking the project, and I'll be forced to maintain my own branch on it.

Being the lazy programmer that I am, I have little desire to maintain my own branch on this. If porting it to PEAR's DB class requires only a little more work than porting it to Postgres directly, and means that someone else will maintain it once the code is merged, then I'm willing to do that.
Now you've got those concepts in mind, ask yourself: Why do I need a relational database? OurPlace (850 pages) uses in-memory objects and serialization, and won't need rewriting to use more efficient storage for quite a while. According to WardsWiki, the average page size is about 1k, which means 1Meg of RAM per 1024 pages. Big whoopie. :) (meanwhile since everything's in memory, searches and retrievals are incredibly fast).
Bleh. ;-)

I'm familiar with your opinions with regards to relational DBMS's, and to a point, I even agree with you. But I do think they are appropriate for certain situations.

Specifically, when all or most of these occur:
  • You're already making use of a relational DBMS for other things, so it's installed, setup, and running, already.

  • You're working with a program that someone else wrote, that was designed as a relational Database front end.

  • When dealing with Perl and/or PHP, 'cause they're just so slick with a relational DBMS.

  • When one of the features that is on the "to do" list is allowing for the upload of binary information, specifically, pictures.
To be perfeclty honest, though, the main reason I'm using a relational database is because, for this project, it's less work to continue using one than to use something else. ;-)

Agreed.

I completely agree.

If they would just take a little bit of time to document what they're doing with PEAR, life would be *so* much nicer.

I mean, as things are now, they don't even have a function reference, or even a function listing, for what's in PEAR. In fact, based just on www.php.net, you'd never even know that PEAR was in development.

If you are interested in it, I've started compiling an (incomplete) collection of documents regarding PEAR, specifically about the DB class. You can see it here: http://tavi.sourceforge.net/DatabaseIndependance.