The Schema Project has achieved a major milestone: The Schema API 1 has been committed for inclusion in Drupal 6 core. The Schema API allows modules to declare their database tables in a structured array (similar to the Form API) and provides API functions for creating, dropping, and changing tables, columns, keys, and indexes. Thanks to Frando for co-authoring the patch with me and the numerous people who helped review and test it.
Documentation for the Schema API is still being written; the work in progress is available at http://drupal.org/node/146843.
Some of the benefits of the Schema API are:
- No more separate CREATE TABLE or ALTER TABLE statements for each database. Module developers only need to create a schema structure and/or use the Schema API functions, and Drupal takes care of the rest. This makes writing install and update functions much simpler.
- Since the API makes it equally easy for module developers to support all databases, Drupal's support for PostgresQL will improve substantially. Also, as new database engines such as Oracle, SQLite, or Microsoft SQL Server are supported, modules using the Schema API will automatically work with them.
- Several advanced capabilities, such as incremental database updates, a simple and consistent CRUD API, form scaffolding, simpler CCK and Views, schema and data validation, become much easier to implement in future enhancements.
Comments
One thing bugged me from
One thing bugged me from when this is in the system: why another special extension? Why was it better then including the schema definition in the .install file? Any particular advantages of the new special extension? You still need to have:
<?phpfunction mymodule_install() {
// Create my tables.
drupal_install_schema('mymodule');
}
?>
Barry, Loads and loads of
Barry,
Loads and loads of thanks for your dedicated work and precious insight on this much awaited improvement.
The day his got committed was a great day for drupal !
That's a good question. The
That's a good question. The answer is "to avoid having the parse all .install files every time the schema changes."
However, the schema does not change often: only when modules are enabled or disabled or when CCK types change. All other times, the schema comes out of the cache, not the .schema files.
Personally, I'd rather see hook_schema defined in the .install file. After talking about with Frando, he more or less agrees, though neither of us thinks it is a big issue one way or the other.
Just so you know, I ended up
Just so you know, I ended up rolling a patch to put schema definitions into .install files here: http://drupal.org/node/155220
I am interested in your work
I am interested in your work here, and I wonder if this can help me with a problem I have. There are lots of modules that have fields that I want to expose to Views, such as Userpoints, Fivestar, etc. I wrote a module called Userpoints Views that specifically exposes several fields, filters, and arguments to Views, but what I'd like to be able to do is create a single module that allows me to expose ANY number of fields from ANY table.
There seems to be no way to programmatically list all tables that a module creates. For example, the Userpoints module creates two tables - userpoints and userpoints_txn. I would need to have a way to tell this, discover the schema for those tables, and dynamically expose selected fields through the admin interface.
Will your work with the Schema module help with any of this?
I was hopeful that Views 2,
I was hopeful that Views 2, the new version that is coming for Drupal 6, would use Schema information (with additional data added by modules) instead of duplicating it in hook_views_tables but Earl told me in Barcelona that it would not. I may yet try to work with him on that for Views 2 or, if not, we'll do for the Drupal 7 version.
Anyway, to answer your question, the Schema API certainly lets you learn what tables a module defines. However, to expose a table to views, you need more info: how that table joins to other tables (particuarly node, though I think Views 2 will not be limited to node-based queries), which database columns should be exported as Views fields, filters, arguments, and sorts, etc. Unless the module provides this info directly (I'd like to see it embedded in the schema structure, Earl wants it in hook_views_tables), you'd have to provide it yourself manually for each module.
earl mentioned two problems
earl mentioned two problems with using schema info. one of them that i recall is that schema does not allow 'faux' fields. that is, fields that have no representation in the DB. Views makes heavy use of this concept. Search for 'notafield' in the Views project for examples.
Post new comment