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.
Related
I am new to Ruby on Rails, so I have some confusion about rails migration.
I want to add a field on my user table, according to rails documentation is only possible by using
rails generate migration add_field_name_to_table_name field_name: type
Question
Is it possible to add fields to the existing database table without rails g migration in rails? Thanks...
The bigger question is why you need to do that. I mean to imply that whatever makes you think that you need to do this is wrong (I am pretty confident about it, assuming you are a new rails user). It is like you would leave your plane without a reason for a long-distance flight to travel by foot.
Answer:
You can do that by:
logging in to Postgres manually like rails db
then creating table manually the SQL way
then adding the table manually with correct columns in your schema.rb file
then creating a model manually
You still will have to repeat this every time this project is cloned anywhere else with no window for mistake. With migration, on the other hand, you will just need to do rails db:migrate
Happy Coding.
Sorry that this question is not a proper one on this site, but I really thought that I needed to know how to do that, because in production environment, if I delete all data all the time when I delete a model, this should be a serious problem.
In detail
In case re-making the same named model,I mean after delete a model, then make the same named model.
It should be like
rails destroy model Name
and after that
rails g model Name
And usually errors occur in this case, we can basically fix the errors by using the command rails db:schema:load, but this command destroys whole data of an existing database, but I don't want to lose the data so I wonder if there are any other good ways for this.
Thanks
Normally, this should not affect your production database, since Ruby on Rails knows what migrations have run already and that's why you should use rails db:migrate to update your database.
If your production database has old entries that you want to reuse, you can also change the Active Record Migrations so that the affected table does not get dropped and recreated but altered instead.
Happy New Year everyone.
In my Rails 4 application I have a table plans containing the records for the plans that a user can subscribe to.
It is absolutely paramount for the app that this table is populated at any time, in development, test, and production mode. Otherwise the app will not work.
What is the best way to create those records?
Should I put a create method into an initializer? Or set up a rake task and run it manually whenever I restart the server (sounds a bit cumbersome, though)?
Thanks for any help in this matter.
Rails has a 'seeds' feature that should be used for seeding a database with initial data.
It's a really simple feature: just fill up db/seeds.rb with some Ruby code, and run rake db:seed
source: http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
If you want to use data in your test environment, you might also be interested in using fixtures for your plans. Take a look at http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures
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.
I've been working on a rails project, in which I need to firstly seed the database and then update the data periodically.
The unfortunate problem is that I seem to want to update the same set of data multiple times. Hence I would like to use the same migration name...but the rails generator seems to complain about the naming.
This leads me to a couple of questions.
Should I even be using migrations to update data in my db or is there an alternative?
How do I get around the naming problems, my assumption was that the timestamp that prepends itself to the migration name would be an adequate differentiating factor?
Thanks
A while back developers used the migration for seeding data. Such was the importance of this need as a core feature and the perceived uncleanliness of this approach, Rails 2.3.4 introduced a dedicated rake task for doing this.
This is now best practice. See this post and this screencast for more info.
For periodic db updating you can add a custom rake task to lib/tasks which works well in my experience.