views is the drupal query builder :)<br><br><div><span class="gmail_quote">On 4/23/07, <b class="gmail_sendername">Wim Leers</b> <<a href="mailto:bashratthesneaky@gmail.com">bashratthesneaky@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think it's inevitable for a project as modular as Drupal and with<br>the amount of modules Drupal has, to eventually need a built-in query
<br>builder, to keep things maintainable and/or to lift the project to<br>"the next level". The question is though, how doable is this? And are<br>enough people willing to work on it? My knowledge about query<br>
builders and SQL is too limited, but I imagine that you can't write<br>this in 2 weeks with say, 10 developers working on it. Something like<br>this needs time, a lot of time.<br><br>Not to mention we also have to somehow provide enough context
<br>information for other modules to hook in whenever desired.<br><br>If it's implemented extremely well, we could simply *always* write<br>"Drupal SQL", and let the query builder worry about the specific SQL
<br>(MySQL, PostgreSQL, Oracle, etc.). That would rock! But what would<br>the performance implications be? I think that a complete query<br>builder in Drupal core might slow down things too much? Or something<br>like the Boost module would have to get in core, to balance the
<br>performance again (virtually no load for anonymous visitors)?<br><br>Just some thoughts...<br><br>Wim Leers<br><br>On Apr 23, 2007, at 11:42 , <a href="mailto:jp.stacey@torchbox.com">jp.stacey@torchbox.com</a> wrote:<br>
<br>> Hi,<br>><br>>>> My opinion on that all depends on what you mean by a query builder.<br>>>> :-) Could you elucidate?<br>>> along the lines of how views does it.<br>><br>> I'd envisage any query builder would be more heavily tied to the
<br>> structure of the underlying database than views.<br>><br>> Rather than adding extra node-based or categories-based options, you'd<br>> explicitly add extra database tables by name, and specify quasi-SQL
<br>> JOIN<br>> conditions and WHERE filtering. At the end of it all it could spit out<br>> some fairly vanilla SQL that matched the structure you'd set up.<br>> Does that<br>> sound right?<br>><br>> (Of course, query builders aren't great at actually optimising the
<br>> SQL.)<br>><br>> Cheers,<br>> J-P<br><br></blockquote></div><br>