[database] [Database] Toward better databases

[Joshua D. Drake]

On Mon, 2008-07-07 at 09:44 -0400, Barry Jaspan wrote:
> Howdy, everyone.  Here's my current brain-dump:

> One snafu, however: db_inspect_column() may require database  
> privileges that other Drupal operations do not.  We'll have to look  
> into that and whether it is an acceptable requirement (the answer will  
> probably be "yes, because there is no alternative").
> 

With PostgreSQL you will not need extra perms. Any user that is allowed
to connect to the database can execute SELECT from
information_schema.* .


> 3.  Larry isn't going to like this, but part of the reason I haven't  
> mustered the time to finish the pgsql driver is that I am not 100%  
> convinced the design for the PDO-based database layer is right yet,  
> and figuring out a proposal to fix it requires more time than I've had.
> 

I am not against PDO but is there a reason we didn't just include a
light and generic wrapper on top of the old fashion functions? Isn't
that what PDO is? (note: not much of a php guy here).

> 3a.  One issue is that the way that SQL and placeholders are generated  
> seems fragile and inefficient to me.  It ends up being fairly awkward  
> for the pgsql driver to keep everything straight in the way it needs  
> to in order to do its most basic function of calling bindParam()  
> correctly (though it is much better than in early drafts of the patch).
> 

Remind me, are we doing client side or server side prepare?

> 3c.  Also, the new database layer is substantially more complex and  
> difficult to understand than our current layer (just trying to  
> determine exactly where queries get executed is a challenge) and I'm  
> concerned it will both meet substantial community resistance and (more  
> importantly) substantially reduce the number of people who are able to  
> contribute to it. 

Some caveats before I say what I am about to say:

Lots of community is good
Difficult APIs are bad

Having an API that is sufficiently well designed that limits the number
of community that could actually develop for it? Good. Weeding out those
who would then subject other community members to potential bad code and
design is not a bad thing.


>  Of course, this is equally true of the Fields in  
> Core project I'm working on, so maybe it is just unavoidable at this  
> point in Drupal's development.
> 

Likely. Drupal is growing up, that means things get a lot more
complicated. Its just the nature of the beast. When I look at PostgreSQL
7.3 versus 8.3 it is amazing how much more complicated the product has
become. It is the nature of adding features, the more features you add,
the more concepts you have to grok. That makes things complicated.

Sincerely,

Joshua D. Drake