Home

draft docs for the registry

user warning: Unknown column 'u.signature_format' in 'field list' query: SELECT c.cid as cid, c.pid, c.nid, c.subject, c.comment, c.format, c.timestamp, c.name, c.mail, c.homepage, u.uid, u.name AS registered_name, u.signature, u.signature_format, u.picture, u.data, c.thread, c.status FROM comments c INNER JOIN users u ON c.uid = u.uid WHERE c.nid = 42 AND c.status = 0 ORDER BY c.thread DESC LIMIT 0, 50 in /home/justin/drupal/6/modules/comment/comment.module on line 992.

draft docs for the registry below. please post additional improvements etc in the comments.

---------------------------------------------------------------------------------------------------------

Drupal's registry

Drupal 7 introduces a code registry - an inventory of all functions, classes and interfaces for all enabled modules and Drupal's core files.

Drupal's module hooks, forms and menu callbacks all utilize the registry to load the code they need to function as needed.

The registry allows all of the code for these systems to be lazy-loaded, which cuts down on unnecessary code loading and parsing.

Modules can now move all of this code into $module.registry.inc, and Drupal will only load it on demand. This will cut down on the amount of code loaded per request, and reduce Drupal's memory footprint.

The only file unconditionally loaded by Drupal for a given module is $module.module. Any code the must always be available without the using the registry should be put in this file. Modules that don't have such code don't need to use a $module.module file, and no code will be loaded up front for these modules.

The registry also loads classes and interfaces on demand, via php's built in class autoloading mechanism.

As the registry is database-backed, there are several layers of caching in place to keep the number of queries as low as possible.

First, all registry lookups are cached per registry rebuild. Even on registry rebuild, the parts of this cache that correspond to files that haven't changed is maintained, making for a very high hit rate. This cache can be cleared via the 'Clear all caches' form on the performance settings page.

The second layer of caching revolves around hook implementations. When the registry is built, we store possible hook implementation information with each resource. This allows us to fetch all modules that implement a hook with a single query, and cache this information between registry rebuilds.