[development] Do not let postgresql hold back great patches
Ivan Sergio Borgonovo
mail at webthatworks.it
Mon Nov 12 11:34:33 UTC 2007
On Sun, 11 Nov 2007 20:14:30 -0600
George Kappel <gkappel at herrspacific.com> wrote:
> I would think this is a slippery slope, making sure a patch work
> against at least 2 db backends in a reasonable way is an important
> indication of quality
Agree.
I think supporting one DB is not just a matter of losing support but
it is a matter of loosing freedom. Once drupal lose the
infrastructure for DB independence, it will be hard to put it back.
Support for 2 DB is actually too few to keep the code sane. The
second will just be a special case of the first rather than an
abstraction.
I am *ing scared of mono-cultures.
No one said DB abstraction had to be easy, actually it isn't and
there are plenty of DB abstraction layers out there to prove it.
I was actually looking at http://www.sqlalchemy.org/ (python) to
learn something.
Any chance we could introduce, get inspired, rely on an existent DB
abstraction layer?
OK, I'll stop to pretend to be a software architect and I'm going to
install D6 on pgsql now to see if I can help in anyway. Installation
completed...
BTW I've some older drupal sites on pgsql. The reasons I chose pgsql
were historical (more mature transaction, stored procedures...).
If I'd have to chose for the future I *may* reconsider to use mysql.
All my pgsql sites are running smoothly even if I had to patch some
modules. I could live with a mysql only D6. I'd just consider it
risky for the future of drupal itself.
Wasn't Microsoft interested in supporting drupal running on IIS/MSSQL?
http://hojtsy.hu/blog/2007-nov-04/adventures-redmond-microsoft-open-source-and-drupal
http://buytaert.net/microsoft-and-drupal
BTW as far as I know there is no way to introduce a unique constraint
in pgsql without eliminating the duplicates first.
For the case exposed here http://drupal.org/node/146466
mysql
ALTER IGNORE TABLE {search_index} ADD UNIQUE KEY sid_word_type (sid,
word, type)");
ALTER IGNORE TABLE {search_dataset} ADD UNIQUE KEY sid_type (sid,
type)
would turn to be
pgsql
delete from {search_index}
where exists ( select 'x'
from {search_index} i
where
i.sid = {search_index}.sid
and i.word = {search_index}.word
and i.type = {search_index}.type
and i.oid < {search_index}.oid
);
alter table {search_index}
add constraint sid_word_type
unique (sid, word, type);
delete from {search_dataset}
where exists ( select 'x'
from {search_dataset} i
where
i.sid={search_dataset}.sid
and i.type = {search_dataset}.type
and i.oid < {search_dataset}.oid
);
alter table {search_dataset}
add constraint sid_type
unique (sid, type);
untested on drupal... tested on a *test* table, going to test further
shortly.
(oid is a bit of pgmagic, oid is the object id, so you're not risking
to kill all the row and leave at least one instance).
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
More information about the development
mailing list