I was told that for some reason, you can't update a database schema when using rails. You can drop a table and then recreate a table with an updated schema, but this won't work if you already have content stored in the table that you want to update.
What do you recommend?
Thanks!
What you were told is incorrect. You can update a DB schema when using Rails.
The way you do it is through "migrations."
A common pattern is to write a set of migrations that build your initial schema. As your app develops, you write other migrations that change the tables and columns to suit the evolving design. If the app is in production, you apply these new migrations to the production schema.
Of course some changes will mess up your existing data, but that has nothing to do with Rails. That would be true regardless of what programming language/framework you're using.
If you have a legacy DB schema and are not using migrations, you can still update your schema by interacting directly with the DB server. Again, what will work and what won't in that situation has nothing to do with Rails. It's totally up to the structure of the schema and the data itself.
If you drop a table in the content in it, the content will be destroyed. You can, however, include content migrations alongside db schema migrations, so it will be migrated back to the table once the schema is updated.
Related
I use the migration file to setup the database structure.
That is very convenient as I am not constrained to a specific type of database (mysql, sql,...)
If I want to have relationships between different tables, I have to use the Associations has_to, belongs_to IN THE MODEL FILE.
I don't get this. Now you can't just roll back a migration of the database go on from this point. No, you also have to modify the model file manually.
Why did they choose this design concept?
Migrations are for changing the state of your database, not for altering the behavior of your models.
I don't get this. Now you can't just roll back a migration of the database go on from this point. No, you also have to modify the model file manually.
Of course you do. You have to modify the model/controller/view code to use any migrated changes to the database, associations or otherwise. What's the big deal? How else would you consume the changes you're making to your database, if not through changes to your application code?
Your application code is always going to be tied to the state of the database. Migrations aren't supposed to isolate you from this.
I'm new to rails and I'm not sure I fully understand migrations. Is there a way to run them without losing table data? Also, is it bad to mess with old migrations to change table structures, or are you just supposed to create new ones?
At version 0 there's nothing in the database. So how do you think you'll be able to keep data? :)
Usually it's not recommended to edit old migrations, because you'll have to reapply them. It's much easier to create new migration and roll it out.
Migrations are nothing but a way to encapsulate the Database used, its just ruby code. Read more here: http://guides.rubyonrails.org/migrations.html
A migration which creates a table is supposed to drop the table when the same migration is reverted(:down). Since it deletes the table there is no chance of retaining data.
Once a migration is executed for a table & you still need to alter structure, you should always create a new migration file for using the generator:
rails g migration AddColumnNameToTableName
I used to think the db/schema.rb in a Rails project stored the database schema, so that ActiveRecord can know what table/column it has.
But earlier I surprisingly noticed that my project runs normally after I delete db/schema.rb!
So, since the Rails can work without it, what does schema.rb really do?
The schema.rb serves mainly two purposes:
It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduce the schema just from the migrations alone. With a present schema.rb, you can just have a look there. ActiveRecord itself will indeed not use it. It will introspect the database during runtime as this is much safer than to expect users to keep the schema.rb up-to-date. However to avoid confusion of your developers, you should always maintain a file that is up-to-date with your migrations.
It is used by the tests to populate the database schema. As such a rake db:schema:dump is often run as part of the rake test:prepare run. The purpose is that the schema of the test database exactly matches the current development database.
Rails Documentation / 6.1 What are Schema Files for?
Migrations, mighty as they may be, are not the authoritative source
for your database schema. That role falls to either db/schema.rb or an
SQL file which Active Record generates by examining the database. They
are not designed to be edited, they just represent the current state
of the database.
There is no need (and it is error prone) to deploy a new instance of
an app by replaying the entire migration history. It is much simpler
and faster to just load into the database a description of the current
schema.
For example, this is how the test database is created: the current
development database is dumped (either to db/schema.rb or
db/structure.sql) and then loaded into the test database.
Schema files are also useful if you want a quick look at what
attributes an Active Record object has. This information is not in the
model's code and is frequently spread across several migrations, but
the information is nicely summed up in the schema file. The
annotate_models gem automatically adds and updates comments at the top
of each model summarizing the schema if you desire that functionality.
Rails documents have you covered.
I'm a PHP programmer for over a decade and making the move to RoR. Here is what I'm used to from the PHP world:
Create DB schema in a tool like MySQL WorkBench -- and make fields precisely the size I want without wasting space (e.g. varchar(15) if it's ip_address).
Write models using Datamapper and place those exact field lengths and specifications in there so my app doesn't try to put in any larger values.
In the RoR world from what I've seen over the past two days, this seems to be the flow suggested:
Add fields / schema using the command line which creates a migration script and apparently created large ass fields (e.g. "ip_address string" is probably making the field varchar(255) in the db when I run the migration).
Put in validations during model creation.
Am I missing something here? What's the process in the RoR world for enterprise level applications where you actually want to create a highly customized schema? Do I manually write out migration scripts?
The scaffolding is what you use to get started quickly. But before running the migration, you can edit it and add constraints and specific column lengths.
Validations specified in the model (in the ruby code) does not carry the same level of security as validations /constraints specified on the database. So you still need to define those on the database.
While it is possible to work with Rails without migrations, I would strongly advice against it. In some cases it cannot be avoided (when working with legacy databases for instance).
The biggest advantage of using the migrations is that your database schema, accross different platforms, can be held in sync through different stages. E.g. your development and your production database. When deploying your code, the migrations will take care that the database is migrated correctly.
You can edit the migration scripts before you run the migration in order to customize the fields.
Yes, if you need to tweak the defaults, you edit the migration scripts.
Also note that you don't need to use migrations, they're a "convenience" while iterating through DB development. There's nothing that says you must use them. The active record pattern doesn't rely on how the DB tables/fields/etc. are created or defined.
For example, migrations are useless when dealing with legacy DBs, but you can still write a Rails app around them.
I'm switching to RoR from ASP.NET MVC. Yeah, migrations are cool, but I do not need to use different databases in my web applications. Postgresql will do just fine.
So is it okay if I use PGAdmin to create and administer my databases and schema and avoid all these fancy migrate, rake etc?
Update
Thanks everyone! Now I better understand what migrations are, and why I should use them.
I don't think that's what migration means.
Migrations in rails (and in other frameworks) is a method by which you can use to update your database schema when there are multiple versions of the same database running
For example, you may have two databases, one running on your production server, and another running locally for development. After a few days of coding, your local development database may looks a bit different. With migrations, you can simply push your code to the production server and then run the migrations to automatically update your production database so it is up-to-date with the one you use locally for development.
So, to answer your question, Yes it is OK but you might not get a few of the migrations niceties when the time comes that you'll have to maintain multiple versions of your database.
Have to agree with charkit but one (rather two) important note why you should use migrations: Migrations don't make up the model definitions. They are stored seperately in a file schema.rb. This defines the rows and tables of your database. When looking into the file, you find these lines:
This file is auto-generated from the current state of the database. Instead of editing this file, please use the migrations feature of Active Record to incrementally modify your database, and then regenerate this schema definition.
The second reason is for testing: you can easily set up a test database to run all your tests against without the need to touch the "real" database. I know when developing, this is not a big problem but this will get more important after some time.
So, yes, it is possible to use PGAdmin to create all your database related stuff but you should not forget to always keep the schema file up to date and come up with a solution for testing.
With migrations you're able to develop your database schema in Ruby and this is usually database indpendent.
In short, spend the 20 minutes or so to really get migrations and the value they add. Then determine whether or not you want to ditch them. Strangely for me I learned Rails before I started my first MVC project; one of the things I missed most was migrations.
From a technical standpoint you should be fine without them.