Posted by recidive on October 25, 2007 at 11:53pm
As mentioned on the other paper A Data API for Drupal. Here is a paper that shows how this could be accomplished with some OOP bits implementing the Active Records Pattern. While keeping the interface procedural.
We all know that Dupal will not go full OOP. But some OOP code could help us do things not possible with procedural code. Such as lazy loading of nested objects and 'on demand' database fields processing.
Before going this route in Drupal core we would need to rigorously benchmark and carefully weigh the risks and benefits. Record module is intended as a step towards enabling us to thoroughly evaluate these options.
| Attachment | Size |
|---|---|
| drupal_active_records.pdf | 100.87 KB |
Comments
Nice work
I read through the pdf and the code and I grokked most of it which is a very good sign. Thats more than I can say for the initial versions of form api. I think this work is really promising. Since Adrian kicked off some of these Data API talks, I'll email him and ask him to weigh in.
I am very glad this is
I am very glad this is getting some work done.
I've only recently began thinking about similar aproaches. this becomes especialy easy with schemas that are available with D6 & modules. combining query building capability of views with available schemas of d6 system we can achieve something great.
this example may not be best but using this approach we can easily eleminate the need for multiple queries to be ran to load a single node! all cck fields and other data can be coupled into a single query in runtime or it may even be cached!
------------------
Sometimes interesting things appears on http://litwol.com
amazing work!
This would be quiet promising from form api front .....
Sree
Small detail
Skip the #, we only use # in arrays if you have a hiearchical structure where you need to distinguish between an attribute and children. Flat structures like hook_link and hook_menu does not use # . Otherwise the proposal is very good. We shall see which implementation works well.
It can be hierarchical
At least, in the RoR implementation, it can be.
<?phpPerson.find(
1,
:conditions =>
{"administrator = 1", "active" = 1},
:order => "created_on DESC")
?>
So I a; not entirely sure if the # is such a bad idea.
http://www.webschuur.com | http://bler.webschuur.com
We implemented an active
We implemented an active record solution at the place I work. I agree performance need to be a key consideration here. Active record solutions tend to make heavy use of joins, and if tables are not properly indexed, this can cause some performance issues. I gave the spec a quick glance, but I will give it more through consideration and add my two cents at a later date
Passing WHERE clause
Passing WHERE clause fragments worries me. That's often a recipe for subtle, difficult problems when the API starts getting used in real code.
For performance reasons, one prefers to use indexed data in WHERE clauses. Can we encourage, or enforce, usage of an API which allows for use of all possible indexed columns in WHERE clauses without actually passing the clause SQL text itself, to avoid such both performance and future syntactical bugs? I'm not sure that's feasible, but it might be an ideal to examine.