Also: http://www.martinfowler.com/articles/evodb.html
On 28.10.2008, at 04:06, Sam Minnee wrote:
>
> Some design questions:
>
> 1) Database versioning. Should we have a table in the database that
> stores information about how up-to-date the database. What should we
> use to track the current version of the database? A timestamp, a
> subversion revision number, or a separate database version number?
> GMT timestamps seem to me to be the simplest as they are universally
> available and you're not coupling yourself to subversion.
How about versionnumbers for each model?
If you take the effort to write a migration script, you might as well
add version numbers to the class incrementally. The currently
applied numbers could be stored for each model (not each table)
in a separate database table.
>
>
> 2) Script format. Should the migration scripts consist of simple .SQL
> statements, ORM calls, or some other syntax? If we're going to make a
> migration syntax, then the ORM is probably a good place to start, but
> we would need to have some way of getting data from no-longer-existent
> tables and columns. This seems like pretty achievable, since the
> legacy dbfields and dataobjects are still available in the database.
SQL-migrations don't work well with database abstraction,
but can be handy if you know what you're doing.
If we can't do both "flavours" of SQL and ORM-based migrations right
away
because of time constraints, I'd start with ORM-based.
>
> 4) Scope. Database content migrations go beyond schema migrations.
> For example, when you create a new page type on a project, you will
> often want to add a new instance of that page type to production when
> you go live, with some particular content. I would think that the
> migration system should be usable for this.
Yeah, not each migration would necessarily change the schema.
Its definetly handy for adding default records - currently we just
check if the table we're about to change has any records to determine
if defaults like a blog page are added.
One important issue for a growing development team is the sequentiality
of migrations - you need to determine an order in which they're
executed.
This means migrations in e.g. feature branches might use a version
number
thats already been reserved in trunk in the meantime, causing weird
database issues.
Might fall in the "too hard" bucket for now...
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
A project that I have seen floating around but haven't used is http://phinx.org/, it is for schema migrations but looks like it can also do data migrations (via queries). I am wondering if it would be worth leveraging a tool like this. I think it would be possible to write a tool that generates for phinx SilverStripe-centric schema migrations à la dev/build, and also their rollback (as a class).