# Schema\_info

**URL:** <https://www.ruby-forum.com/t/schema-info/93753>\
**Category:** Rails\
**Created:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/schema-info/93753 "2005-11-12T12:49:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![netghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/87869e/32.png) [@netghost](https://www.ruby-forum.com/u/netghost)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/schema-info/93753/1 "2005-11-12T12:49:22Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![netghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/87869e/32.png) [@netghost](https://www.ruby-forum.com/u/netghost)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/schema-info/93753/2 "2005-11-12T12:49:22Z")

</div>

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.

- Jamis

---

<div class="post-metadata">

**Author:** ![netghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/87869e/32.png) [@netghost](https://www.ruby-forum.com/u/netghost)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/schema-info/93753/3 "2005-11-12T12:49:22Z")

</div>

-----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-----