So what's the best way to create new tables in a Sqlite database in Rails 2. I have created the database using rake db:migrate command. So should I write individual sql scripts to create a database or use rake somehow. I don't need scaffolding.
Basically use migrations.
Some useful help on how to use migrations is available at http://wiki.rubyonrails.org/rails/pages/understandingmigrations and http://wiki.rubyonrails.org/rails/pages/UsingMigrations. A good cheatsheet that I use is also available at http://dizzy.co.uk/ruby_on_rails/cheatsheets/rails-migrations.
Basically migrations use ruby code to create your database tables for you. It is far easier (in my opinion at least) to use nice ruby code to do this rather than SQL DDL - it also does various things automatically for you (like adding id fields to all your tables as rails requires). You can then use rake tasks to actually apply the migrations to your database. The other major advantage that migrations give you is that they are reverseable - so your database is versioned and you can easily jump from one version to another.
Try to avoid writing CREATE/ALTER table scripts and use ActiveRecord migrations instead. A few reasons spring to mind:
Portability: it's much easier to let
AR deal with cross-platform flavour
differences
Change control: your
migrations can manage changes in
both directions with the VERSION=
option, something that's not easy to
do with SQL
It's the Rails way:
follow the Rails conventions unless
you have a compelling reason not to
do so
Simplicity: you don't have to worry about id and timestamp columns when you use migrations, which saves you having to remember them if you work in SQL
If you are not using scaffolding then you should use script/generate migration to create a migration file for each table. There is no need to use sql scripts. After creating some migrations you can apply them to your database using rake db:migrate.
Related
The question pretty much says it all.
I'm new to Ruby and Rails and I'm trying to figure out active record. According to a few pieces that I've read, Rails will interrogate the database (in my case PostgreSQL 9.6) and pick up the columns from that. The way I read this, does that mean I can create the database in PostgreSQL, create ORM classes and define the relationships in the ORM classes?
My background is in databases and it's been a while since I've done any web development and prior to 1/8/2018 I had never even touched Ruby let alone Rails. So, the ultimate question is: Can I create the database in PostgreSQL without Rails migrations and then create the ORM classes with the relationships between the classes (tables) defined in them?
Yes, absolutely! You'd just need to connect to the existing db in config/database.yml and generate a schema file by running rake db:schema:dump. Remember to go by Rails naming conventions for ORM Classes (called Models in RoR). You can also explicitly set table names for every model by adding self.table_name = "posts" (see this answer)
I'm learning Ruby on Rails and it talk about how Migration changes the state of the database by using the command bundle exec rake db:migrate, but what exactly does that mean?
Migrations are a way of defining the schema of your database. Rails provides an API for adding/dropping/modifying database columns and tables using Ruby code. These files are knows as migrations. Here is a link to the documentation: http://edgeguides.rubyonrails.org/active_record_migrations.html,
but migrations are not a concept unique to Rails. For example, Django also uses migrations to manage the state of the database. The short answer is that migrations are a code-based way to manage the structure, or schema of your database.
It executes all the migrations that you created/generated via rails generate migration X.
Basically migrations are scripts that deal directly with the database (creating tables, fields, indexes). Hope that helps! :)
I want to create a Rails app but I have a question before start it.
I have defined a database model in paper (about 15 tables) and I don't know which is the best way to start the application:
Create the tables on database with my database client and after that in console do:
rake db:schema:dump
with this I will obtain the shema.rb and after that do a :
rake db:migrate
or
In console, one to one, create the models, edit them with an editor and do:
rake db:migrate
I think the first one is more quickly but the second I think is better from the point of view of rails.
I am bit confused about that, can anyone help me with this question?
Rails mean the only sure way to create a database for a new application - migration.
You can create a single migration for all of your application but such migration is not easy to roll back.
Therefore wise to create a migration for each table.
Normal situation when you have 100,500 migrations in the end. For that you get your application is ready for deploy to combat server.
Permitted the creation of migration through model and scaffold or independently.
Why not use a generator?
rails g model User first_name last_name age:integer email user_name
You don't need to specify type if it's string. This will generate model class and migration.
I think there may be varying viewpoints on this issue.
Also, it depends if you're using the rails built-in sqlite database.
However, assuming that you do use the default rails db configurations,
I personally prefer the second choice.
Later, you might want to change some parts in your tables.
If you follow the rails way of doing so, this process will be very easy and less confusing.
Also, you can always add custom ruby scripts for pre-loading with data.
Of course, other people might find the other way easier.
Is is correct to assume that migrations in ruby on rails are simply updates to any database. And that the rake db:migrate script only serves to actualize these changes?
Yes.
Migrations are a convenient way for you to alter your database in a
structured and organized manner. You could edit fragments of SQL by
hand but you would then be responsible for telling other developers
that they need to go and run them. You’d also have to keep track of
which changes need to be run against the production machines next time
you deploy.
Active Record tracks which migrations have already been run so all you
have to do is update your source and run rake db:migrate. Active
Record will work out which migrations should be run. It will also
update your db/schema.rb file to match the structure of your database.
Migrations also allow you to describe these transformations using
Ruby. The great thing about this is that (like most of Active Record’s
functionality) it is database independent: you don’t need to worry
about the precise syntax of CREATE TABLE any more than you worry about
variations on SELECT * (you can drop down to raw SQL for database
specific features). For example you could use SQLite3 in development,
but MySQL in production.
Source: Ruby on Rails Guides: Migrations
I am presently designing a database schema for use in a Rails 3.1 application.
At the moment, I am using MySQL Workbench to design the schema visually, and then manually translating this to Rails migrations & models.
Can anyone indicate if there are any solutions that will allow a schema to be designed visually and translated automatically (i.e. via script) to Rails?
Thanks!
First off, the "database-first" approach definitely isn't really the preferred way to work with Rails... but if you really want to...
If you generate the the tables from your schema you can configure the Rails app's config/database.yml file to connect to your database, then call rake db:schema:dump which generates the db/schema.rb file from the database. Then you can create a migration and copy the code from db/schema.rb into the change (or self.up) method.
Note that this does not automatically create model classes - you'll have to create these yourself, remembering to --skip migration in the rails generate model, and possibly needing to make liberal use of the set_table_name (to map the model class to the right table name), alias_attribute (to map model attributes to the right columns), and perhaps set_primary_key.
There were some more complete approaches to this sort of thing for older versions of Rails (Magic Model Generator and reverse_scaffold are two that I've found), but I don't know of any that have been upgraded to work with Rails 3.
SQL Editor is a Mac application that allows you to visually design a DB schema and then export it as something you can easily import as a schema in Rails.
You will still have to create the models yourself.
For rails existing applications or the new application, you can use this for db design
https://dbdiagram.io/
I use railshelper.com which helps me in a simplistic manner to generate quickly some common rails cli commands !
I think Mogwai ERD will help you out, there you can design your ERD and convert it in to a DB schema.
And I think there is no software for design Rails schema, it's just that you make your schema adhere to Rails conventions. But of course Rails can be configured to almost any schema.