[development] MYSQL queries and Modules

Pierre Rineau pierre.rineau at makina-corpus.com
Sun Feb 27 21:03:23 UTC 2011

On Sun, 2011-02-27 at 11:31 -0800, nan wich wrote:

> Ah, see now you say that 10% of hook_init's are appropriate, so
> telling someone to always avoid it is bad advice. In all the coding
> that I have done, I have used hook_init() maybe three times (twice I
> know for sure). And one was largely a toss up between hook_init() and
> hook_boot() and I can guarantee was needed. And you probably add
> hook_exit() to the list of questionable usage.

Don't make me say something I didn't mean. What I really meant is that
hook_init() should never be used, some modules legally uses it as a way
to set up some context related information because no other helpers
exists in core (that's actually part of the butler project on g.d.o).
But aside of that, all hook_init() implementations should be banned. In
fact even existing one (I'm thinking about D6 OG module) can show
themselves being incredibly slow under certain circumstances.

> In the case where I created my own cache file, it was more an attempt
> to "help" the database keep the data available because rebuilding the
> data (taxonomy-based) could get quite heavy in certain circumstances.
> When I convert the module to D7, I may not need any of that because
> field data may already be cached any way. As a matter of fact, 90% of
> the module may no longer be needed.

If you choose to separate your own cache for logic and business reasons,
this is totally valid.

For actual D7 core implementation, I'm not sure fields are cached,
that's something that the entity API attempt to resolve. They didn't
figure out a nice way to do it in core before the D7 release.


More information about the development mailing list