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 _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Nov 8, 2005, at 1:40 PM, Adam Sanderson 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. - Jamis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 8, 2005, at 12:40 PM, Adam Sanderson 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. > > 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-----
> > 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.Well then what about making the table more useful? For instance a timestamp field would help track when the schema was changed, or a log of the sql executed... Just some thoughts. .adam _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 8, 2005, at 2:05 PM, Adam Sanderson wrote:> Well then what about making the table more useful? For instance a > timestamp field would help track when the schema was changed, or a > log of the sql executed... Just some thoughts.Or using an AR model with some duck-typing expectations: config.active_record.migrations.schema_info_class = MyClass jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDcSvbAQHALep9HFYRAsZGAJ4iB566ETg8qQBPzBcxJolF7crY8QCgrNQj 0sSwH1HnnEAl4KW/hGywO0A=Blmb -----END PGP SIGNATURE-----