wordpress-pg-devel

[WP-pg-devel] WordPress-pg 1.2.1-1.0 released.

[Keenan T. <kt...@go...>]

Lame versioning, yeah, but it's been released.  I think if this project 
is going to get much more work we need something more sane.  Perhaps 
just appending another number after the core WP version, ie. 1.2.1.0 is 
more appropriate.  I think I'll switch after the next revision.

What's necessary in HEAD right now?

-- 
Keenan Tims
kt...@go...
PGP: http://www.gotroot.ca/pubkey.asc

Re: [WP-pg-devel] WordPress-pg 1.2.1-1.0 released.

[William A.C. <wil...@ca...>]

On Oct 21, 2004, at 9:13 PM, Keenan Tims wrote:

> Lame versioning, yeah, but it's been released.  I think if this 
> project is going to get much more work we need something more sane.  
> Perhaps just appending another number after the core WP version, ie. 
> 1.2.1.0 is more appropriate.  I think I'll switch after the next 
> revision.
>
> What's necessary in HEAD right now?

HEAD is still a bit of a mess at the moment.  It's a merge of the CVS 
from the WordPress project with what they've done leading up towards 
their 1.3 release.

You can do a clean install from HEAD right now, and at least the 
install process doesn't seem to fall on its head any more after a 
fairly significant amount of tweaking.  It builds the tables and the 
indexes and seeds the initial information.  I added referential 
integrity constraints for at least the time being in some obvious 
places.

However, the following is still broken:
* upgrades from any previous version and presumably the import tools
* actually displaying any content after the install

The WordPress folks pretty much overhauled the creation and upgrade 
code for the database schema.  It depends on all sorts of hooks in 
MySQL not to hit its head too badly and I've only made progress on some 
of them.  They've added a plethora of new fields to the database, 
except the codebase doesn't seem to use many of them, and PgSQL doesn't 
really care for some of the defaults they picked..

Some of the enum substitution stuff you had done previously got lost 
when the schema info moved to a new file.  Still need to go back and 
actually put a check on those to enforce the choices properly.  Several 
"enum('y','n')" and similar things I've changed into PgSQL's Boolean 
type.  It takes y, n, yes, no, 1, and 0 which seem to be the usually 
suspects on those fields, and it should be a bit more efficient for 
lookups.

That's about it so far.  I've talked a little bit with some of denizens 
of the #wordpress IRC channel on Freenode to try and get a feel for 
what their plans are with the schema.  They've said that the schema is 
not likely to change much between now and release.  The repeated use of 
'' and 0 instead of NULL for all these new unused fields devoid of 
content makes me kind of sad.  I imagine plugin authors are 
unfortunately going to count on these so they can't be changed.

Oh yeah, and I'm testing on OS X with Pg 7.4.5, Apache 1.3.29 and PHP 
5.0.1 now during active development.  I'll move back to testing with 
the FreeBSD system once things gel a little more.
-- 
Andy

Re: [WP-pg-devel] WordPress-pg 1.2.1-1.0 released.

[Keenan T. <kt...@go...>]

 > However, the following is still broken:
 > * upgrades from any previous version and presumably the import tools
 > * actually displaying any content after the install

Okay, I'm going to try to find some time this weekend, if things aren't 
too crazy, to get some hacking done.  The other thing I thought I'd 
mention is that the MD5() function isn't present in Postgres before 
7.4...and as far as I know all current versions of RedHat ship with 7.2. 
  It's easy to do, but I think we should move all that stuff over to 
PHP's md5 function instead to improve the usefulness of this code.

 > Some of the enum substitution stuff you had done previously got lost
 > when the schema info moved to a new file.  Still need to go back and
 > actually put a check on those to enforce the choices properly.  Several
 > "enum('y','n')" and similar things I've changed into PgSQL's Boolean
 > type.  It takes y, n, yes, no, 1, and 0 which seem to be the usually
 > suspects on those fields, and it should be a bit more efficient for
 > lookups.

We may as well take this opportunity to make the non-boolean enums into 
a proper relational type, perhaps we can even utilise Postgres' powerful 
(so I'm told) custom types.  Text comparison might be faster, but I 
sorta doubt it, and it's counter-intuitive.  The proliferation of 
MySQLisms in the WordPress code is rather disheartening.  I would've 
hoped such lauded code would be more consistent and 'correct'.  Not a 
huge job to change though.

Good to see some testing on PHP 5.  Haven't had much chance to 
experiment with it yet.

Also, my internet still seems a bit flaky here.  The phone company, of 
course, denies responsibility.  If you get e-mails bounced back or 
anything, just resend them, the outages only last a few minutes.

-- 
Keenan Tims
kt...@go...
PGP: http://www.gotroot.ca/pubkey.asc