[development] versioned schema?

Peter Wolanin pwolanin at gmail.com
Mon Jun 11 18:39:06 UTC 2007

On 11 Jun 2007 00:03:03 -0400, Barry Jaspan <barry at jaspan.org> wrote:
> "Peter Wolanin" <pwolanin at gmail.com> writes:
> > To me this suggests that there should be a way having several
> > different schema in the .schema file with different version numbers.
> Yes.  I intentionally left this out because I wasn't sure of the best

I think that a combination of #1 and #2 might make sense:

For each different schema there is a convention to have a function
like hook_schema_6000().

hook_schema($version = NULL)  can then just dispatch the right
version.  The developer has to manually set in the hook_schema code
which is the most recent - i.e. what is returned if $version == NULL,
and which to return for any other value of $version.

A potential advantage of this - if you look in the system table and
see that schema == 6023, but update 6023 did not change the table
structure ()see, for example, function system_update_1002()),
hook_schema can easily return the same schema for hook_schema(6022) or
hook_schema(6023) i.e. "return hook_schema_6022();".


> way to do it (or even a necessarily good way).  Some options:
> 1.  hook_schema_1(), hook_schema_2(), etc.
> 2.  hook_schema($version = SCHEMA_CURRENT)
> 3.  Optionally encoding a version number with each element of the
>     schema; "this field was added in version 3", "this index was
>     removed in version 4."
> I kinda like #2 the best, but #1 may make more sense with our current
> hook_update_N() system.  (#3 has the "advantage" that we might be able
> to automatically update from one version to the next, but it could
> also be very complicated.)  Perhaps hook_schema_N() and
> hook_update_N() should be tied together in some way so that the new
> schema and the upgrade path to get to it from the previous one are
> always specified together.
> Feel free to make a proposal. :-)
> Thanks,
> Barry

More information about the development mailing list