Database

This group should probably have more organizers. See documentation on this recommendation.

This is a working group for those involved in the development and extension of Drupal's Next Generation database abstraction layer, including the Schema API and the development of new database drivers.

Please remember to read the documentation for the Database API. It will likely be helpful to review the PDO documentation as well.

Active Records, a possible approach for consistent Data APIs

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.

Data APIs for Drupal 7 and web services support

Posted by nedjo on October 25, 2007 at 7:21pm

There's growing interest in the Drupal community in the prospect of renewing our core data handling APIs. Doing so will increase consistency and efficiency and ease barriers. It will also be a key step in enabling transactional web services.

In Drupal 6 we took some impressive first steps. What should we tackle for Drupal 7?

The attached paper, written by Nedjo Rogers and Henrique Recidive and sponsored by CivicSpace, aims to carry this discussion forward and map out both some conceptual space and concrete development tasks.

Table creation order

Posted by bjaspan on June 12, 2007 at 1:48am

Once foreign keys are specified during table creation, we will have to make sure to create tables in the correct order. e.g. You can't create system.schema, whose files table has a uid column, before you create user.schema which creates the users table which hold the master uid column.

If this proves too difficult we can use ALTER TABLE to put the foreign key contraints in afterward, but that seems much less desireable.

Add join/foreign key info to schema

Posted by bjaspan on June 1, 2007 at 5:31pm

Now that we have four more weeks before D6 code freeze, maybe it is possible to add join relationships/foreign key support into Schema API 1 after all. Otherwise, it will be another year before this info is in core. Note that this info does not really have to be in core---it can be added by a contrib module hook_schema_alter. But a lot of people would be pretty psyched to have referential integrity for pgsql built in to D6.

Additions to the API

Posted by drewish on May 28, 2007 at 7:23pm

Now that the schema has been committed to core, I wanted to open up a thread where people could discuss additions an enhancements to the API.

I posted a patch to add a db_rename_table over on #147285. I've love to see it get in before the feature freeze.

Defining Schema data types

Posted by bjaspan on April 24, 2007 at 1:35pm

Now that Schema almost has a driver for PostgreSQL I needed to resolve the data type issue. I like Frando's approach (I seem to say that a lot) of storing 'type' and 'size' separately because it makes a variety of things easier. For example:

$schema['mytable'] = array(
  'cols' => array(
     'col1' = array('type' => 'int', 'size' => 'big', ...)));

Random ID Generation Write up

Posted by Souvent22 on April 24, 2007 at 2:58am

So, I've had a few inquiries over the last few months about random node generation as I have implemented it successfully for a client. I have posted a full write up of it on my blog. Feel free to comment on it here or on my blog; I will post a patch when I have a chance and if there is interest.

Article link: http://earnestberry.com/node/13

Using database schema to load nodes in fewer queries

Posted by bjaspan on April 17, 2007 at 4:23am

One thing that becomes possible when Drupal can access its own database schema is that queries which currently are performed separately can instead be performed together. In particularly, I think it might be possible to load an entire node with a single SELECT query or, at least, in far fewer than Drupal currently uses. Working proof of concept code is already in the Schema module; it loads all CCK fields, comments, and author info in one query. Loading more things only requires adding a join entry to the schema data structure (see below).

Defining the schema data structure

Posted by bjaspan on April 16, 2007 at 8:59pm

One of the first things we to do is define the data structure that modules will use for declaring their tables. Schema module, Frando's patch, dopry's patch, and CCK fields all use different structures though their underlying approaches are basically the same. We need to decide what kind of information the data structures must contain and can contain. This will obviously include at least columns (name, type, length, nullable, default), indices (name, columns, primary vs unique vs multi), and join/relationship information.

Welcome and background

Posted by bjaspan on April 16, 2007 at 3:54pm

Welcome to the Database Schema API group. A number of different Drupal developers have independently suggested and/or coded various approaches to abstracting table creation/alteration. The idea finally seems to have reached critical mass and I suggest that we will be best served by combining everyone's efforts on the topic. Hence, this group.

By way of background, here is some recommended reading on the topic:

Subscribe with RSS