The migrations system is complex and has always felt brittle to me. A refactor would probably be useful.
Changes
Structure of migrations files: Right now migrations consist of a file for every table, and that file is basically a history of change diffs for that table. This doesn't take into account the relationships between those tables, i.e., the histories of two connected tables are separate. The linear migration histories used in Rails and Django don't have this problem. So, the solution I'm thinking, is having the migrations directory be a list of numbered JSON/XML files, each having some metadata (When the migration was made) followed by the actuall diff of changes.
Use JSON or XML instead of S-exps: Security reasons, mostly. Another is certainty: The alphabet of JSON is narrower than what the Common Lisp reader can read.
Keeping track of the current migration: The ID of the current migration could be kept in three different places: The database (Contaminates the data), a file in the migrations directory (Needs to be explicitly kept from source control), or a global cache in Crane's installation directory. I'll probably end up storing it in the database.
Leverage CLOS more: The migrations system could use some object orientation. Currently you have functions that return plists, Clojure-style. This is problematic, since you have remember the structure of some function's output to write code in another, rather than working with a plain old fashioned interface.
Disable automatic migrations: A simple value in the configuration will do.
Synopsis
The migrations system is complex and has always felt brittle to me. A refactor would probably be useful.
Changes