Migrations seems to be a fair solution to propogating changes to a
database
structure, but I think the schema_info table might be a bit overkill.
Why a
separate table instead of just a file in /conf or /db ? Assuming that
file
isn’t placed in someone’s source repository it would be unique to the
installation.
I really don’t like seeing framework specific tables in my schema. It’s
one
of the benefits of ActiveRecord over a number of other OR mappers and
frameworks.
Anyways, just a thought.
.adam sanderson
On Nov 8, 2005, at 1:40 PM, Adam S. wrote:
Migrations seems to be a fair solution to propogating changes to a
database structure, but I think the schema_info table might be a
bit overkill. Why a separate table instead of just a file in /
conf or /db ? Assuming that file isn’t placed in someone’s source
repository it would be unique to the installation.
I really don’t like seeing framework specific tables in my schema.
It’s one of the benefits of ActiveRecord over a number of other OR
mappers and frameworks.
It seems to me that the database is actually a pretty natural place
to store this data. It is metadata about the database, and as such,
it is really inseparable from the database. It has no meaning to
anything else. If you use another framework to access your data, the
schema_info table still has meaning, because it tells you the current
“age” of the schema.
By putting this info in a location external to the database, you’re
increasing the risk of the schema information being lost. If you move
your database to another machine, you have to remember to copy that
little information file, too, which is easy to forget. Same with
backups. If the schema info is packaged with the DB itself, backups
and so forth will always preserve the current schema version,
automatically.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Nov 8, 2005, at 12:40 PM, Adam S. wrote:
Anyways, just a thought.
The info needs to be in the DB, but perhaps it doesn’t need a special
table: the evidence of a migration is in the changes it has made.
Introduce Migration.performed? that introspects on the DB to check
whether its changes have been made. Working with a database’s
timeline is natural:
up_to_date = migrations.all? { |m| m.performed? }
current_version = migrations.select { |m| m.performed? }.last
out_of_order = migrations.inject(false) do |found_pending, m|
break true if found_pending and m.performed?
!m.performed?
end
However, this requires the additional effort of implementing
performed? for each migration.
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFDcRkuAQHALep9HFYRAjY7AKCovucqTAna6EkjIuXcDL61nFcy4wCg4r0/
yUPDgCXXnLygXn5cWRXn4BI=
=if5H
-----END PGP SIGNATURE-----