cxjohnson at gmail.com
Tue Apr 24 13:39:01 UTC 2007
As Larry mentioned, just what do we mean when we say "query builder?"
And just exactly why do we need one? Let's try to be specific and
write out both a definition and the reasons for having one in Drupal
core. What are the benefits? What are the drawbacks? And, what are
the alternatives? Maybe some other form of abstraction would actually
be a better choice for Drupal core.
Here is starting point on some specifics.
* Definition of a query builder (in our context and plans)
-- Are we discussing the constuction of something that will take
all of the "normal" database queries needed to generate a page into
consideration and then build a more optimal, smaller number of queries
to retrieve the data (per Larry's remark about views saving a ton of
SQL by doing something along these lines)?
* Reasons for having a query builder in core
-- Saving developers from struggling with complex code to retrieve
data, at the cost of SQL statement complexity and performance.
-- Possibly optimize number of queries per page.
* Possible Alternative Abstractions (just blue sky ideas at this point)
-- Define once and for all the first class objects for core, and
write CRUD operations for the _objects_.
-- Abstraction library maintained by "core SQL" developers, through
which all access will flow.
Let's be explicit about what we are really trying to accomplish -- the
goal, not the implementation -- and then detail the characteristics of
an implementation which will attain that goal. This is too key and
too large an effort to be less rigorous about it, I think.
More information about the development