[development] Re: enterprise needs

[Khalid B]

On 2/27/06, Darrel O'Pry <dopry at thing.net> wrote:
> On Mon, 2006-02-27 at 18:25 +0200, Adrian Rossouw wrote:
> > On 27 Feb 2006, at 6:11 PM, Darrel O'Pry wrote:
> >
> > >
> > > with 1) you may get slightly better performance since you aren't
> > > constantly parsing strings, but you start making some major changes to
> > > drupal's db_abstraction layer.
> > How long before it makes sense to just use a third party db
> > abstraction library ?
> >
> > I'm not hot on the idea of re-inventing the wheel yet again.
> >
>
> Neither am I unless we can improve on the original. Do you have any that
> have been in mind that will work for drupal?
>
> I  think db_rewrite_url will be hard to find an equivalent for but I'm
> sure we can hack that in... I'd ideally want support for
>
> 1) mysql
> 2) postgresql
> 3) oracle
> 4) db2
> 5) sqlite
>
>
> features I'd like to see are
> 1) replication/cluster support
> 2) query result caching
> 3) transaction support

I think we are going overboard here. Support in core for all these bells
and whistles is overkill. If this is pluggable, then I am not against it,
but to be a standard feature, even for shared hosts, then I am.

As for a db abstraction layer, I am conflicted on this.

- It creates an external dependancy (e.g. PEAR DB)
- We may be able to bundle it to get over this.
- Remember the xmlrpc fiasco? We relied on something external, then had
security issues, and re-wrote it inhouse.

On the other hand:
- Why reinvent the wheel?
- NIH (Not invented here)?
- We can do with better support for other databases, e.g. SQLite,
better support for PostgreSQL, and whatever will happen because of the
Inno/Sleepcat/Oracle thing.