[development] db_rewrite_sql question
rob at torenware.com
Tue Aug 15 22:12:21 UTC 2006
While I personally think that hook_db_rewrite_sql is The Devil's Work,
there are a couple of ways around this feature of the hook.
First, if you can, make use of the "primary table" parameter.
The second is easier, or harder, depending upon how much code you have
in your module. The best advice is to use a more descriptive variable
name than $cid, assuming it's your variable, and not out of one of the
The best would be if in 4.8, the d**n hook was redesigned to make it
easier to be clear when you want your hook implementation to get called,
and when you don't want to get called. There is currently no easy way
to avoid this kind of problem. With the increasing use of the Views
module, we're going to get more and more conflicts creeping in via
db_rewrite_sql problems like this.
Dave Cohen wrote:
> I wrote a module called cac_lite which provides simple access control for
> users of the category module. One of the things it does is rewrite sql
> queries where the $primary_field is 'cid' (category id).
> Now I've learned of another module (Comment RSS) that also calls
> db_rewrite_sql with $primary_field 'cid'. But in this case 'cid' stands for
> comment id.
> The effect is that cac_lite rewrites a sql query that it shouldn't rewrite.
> So users can't have commentrss and cac_lite installed together.
> The underlying problem is that implementers of hook_db_rewrite_sql have no
> accurate test for what the fully-qualified primary field is. They are passed
> a $primary_table, but this is usually an alias of the table's real name. For
> instance, when commentrss calls it, $primary_table is 'c' and not 'comments'.
> When category calls it, $primary_table is again 'c' and not 'category'.
> What's a module to do when it recieves two calls to hook_db_rewrite_sql; in
> both cases $primary_field is 'cid' and $primary_table is 'c', but in one case
> the query needs re-writing and in the other it does not?
More information about the development