enterprise needs

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

On 2/27/06, Darrel O'Pry <doprything.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.

> 2) query result caching

modules are welcome to use the cache_set/cache_get API for
this. 
forum.module used to o this, but it was removed when
node_access went 
in. this really makes sense only for expensive queries that
aren't 
personalized and i can't think of any of those in core
right now.

On Mon, 2006-02-27 at 11:49 -0500, Moshe Weitzman wrote:
> > 2) query result caching
> 
> modules are welcome to use the cache_set/cache_get API
for this. 
> forum.module used to o this, but it was removed when
node_access went 
> in. this really makes sense only for expensive queries
that aren't 
> personalized and i can't think of any of those in core
right now.

I'm just thinking per run. I thought db_query already did
that... But
looking at the code in head it doesn't...

I would at the least like to see some form of transaction
support, and 
support for master/slave database clustering and
replication. 

I should probably stand down from this discussion as won't
be
implementing anything related to the db abstraction until
the file
handling is is somewhat better than palatable.

Moshe Weitzman wrote:
>> 2) query result caching
> 
> 
> modules are welcome to use the cache_set/cache_get API
for this. 
> forum.module used to o this, but it was removed when
node_access went 
> in. this really makes sense only for expensive queries
that aren't 
> personalized and i can't think of any of those in core
right now.

The forum index page is both personalized and *massively*
expensive.

jh