[development] db_rewrite_sql

[Wim Leers]

I think it's inevitable for a project as modular as Drupal and with  
the amount of modules Drupal has, to eventually need a built-in query  
builder, to keep things maintainable and/or to lift the project to  
"the next level". The question is though, how doable is this? And are  
enough people willing to work on it? My knowledge about query  
builders and SQL is too limited, but I imagine that you can't write  
this in 2 weeks with say, 10 developers working on it. Something like  
this needs time, a lot of time.

Not to mention we also have to somehow provide enough context  
information for other modules to hook in whenever desired.

If it's implemented extremely well, we could simply *always* write  
"Drupal SQL", and let the query builder worry about the specific SQL  
(MySQL, PostgreSQL, Oracle, etc.). That would rock! But what would  
the performance implications be? I think that a complete query  
builder in Drupal core might slow down things too much? Or something  
like the Boost module would have to get in core, to balance the  
performance again (virtually no load for anonymous visitors)?

Just some thoughts...

Wim Leers

On Apr 23, 2007, at 11:42 , jp.stacey at torchbox.com wrote:

> Hi,
>
>>> My opinion on that all depends on what you mean by a query builder.
>>> :-)   Could you elucidate?
>> along the lines of how views does it.
>
> I'd envisage any query builder would be more heavily tied to the
> structure of the underlying database than views.
>
> Rather than adding extra node-based or categories-based options, you'd
> explicitly add extra database tables by name, and specify quasi-SQL  
> JOIN
> conditions and WHERE filtering. At the end of it all it could spit out
> some fairly vanilla SQL that matched the structure you'd set up.  
> Does that
> sound right?
>
> (Of course, query builders aren't great at actually optimising the  
> SQL.)
>
> Cheers,
> J-P