Forum: Ruby on Rails schema_info

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
65bd9e4c5aebde25ebf16d599339d570?d=identicon&s=25 netghost (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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
992fe8c19bbbc27f2b562a9f96efc03d?d=identicon&s=25 jamis (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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
24d2f8804e6bb4b7ea6bd11e0a586470?d=identicon&s=25 jeremy (Guest)
on 2005-11-12 12:49
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 8, 2005, at 12:40 PM, Adam Sanderson 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-----
This topic is locked and can not be replied to.