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@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