I am currently using Bitbucket and am handling a Ruby on Rails repository across users. By default, when one user pushes the repository(default command - git push origin master -entire rails folder), I assume that the db also gets pushed to bit bucket, right?
When a second user downloads the repository off git, shouldn't i expect all the db files to also get downloaded?
Is it necessary for the second user to run rake db migrate commands again after downloading the file?
In the specific case above, I am the second user and I get the following error message upon downloading the repository off BitBucket, while the file run perfectly on the uploaders computer:
ActiveRecord::StatementInvalid in StaticPagesController#home
Could not find table 'users'
I want to make sure that both of us are working on the same DB and are not working in parallel on different datasets.
Data in your database will reside only in database. It will not be in git repository. The repository contains database config files and migration files to create databases on the fly. Again, it doesn't contain data.
If you want to work on the same database, I would look into using Amazon AWS RDS. Setting up RDS is not undoable, but it's not trivial enough for me to expound on exactly how you do that here.
I guess you are new to Rails. The way Rails handle database in development is :
with database structure:
You maintain the structure through migrations file.
Yes, if you pull new code that does contain new migration file, you
need to run rake db:migrate. You will notified if you don't.
with database data:
In development, you can maintain data to test through seed file. You can watch this great screencast here: http://railscasts.com/episodes/179-seed-data
Better, you should use seed_fu gem https://github.com/mbleigh/seed-fu
Related
I have created an application with Ruby and Rails. The thing is that when I was develpoing it, I had some problems with the migrations, because I created them but with a wrong syntax. What happened is that I deleted some of the files because sold migrations that didn´t work had the same name than the new ones, but in the middle of that I accidentally deleted some of the migrations (obviously after running rails db:migrate) that the project uses actually. So for instance, i have the Service table, which is related to the Reservation table because Service has reservation_id, but i don´t have the migration file that says AddReservationIdToService.
So now I want to use Heroku for production. the thing is that O have to change to postgresql because Heroku doesn't support sqlite. So i have to run the de:migrate again to create the tables and relationships in the new DB, but I need the files that I explained that I deleted. The question is:
Can I create the migrations manually, so when i run db:migrate for postgres the full structure of the database is created without lacking relations?
You don't really need the migrations to recreate the existing DB -- in fact it's not a good idea to try for a couple of reasons (including the missing migration file problem you encountered). You can simply run:
bin/rails db:schema:load
to populate a new database from the existing schema. If for some reason you haven't got a db/schema.rb checked under version control you can run:
bin/rails db:schema:dump
against the sqlite version to re-create a fresh schema file from the database.
You can also keep your migrations list tidy by occasionally zapping really old migrations, since all the cumulative changes are captured in the schema file.
Yes, you might create another couple of migration files.
Certify you have now the tables you wish locally with your sqlite. Draw these table in a piece of paper (or where it be the best fr you), then check this official API documentation of Rails.
Delete all migrations made before and create another according to the tables you drew.
The workflow is gonna be like:
1) "I need to create a table called Reservation, where is it shown on the documentation?"
2) "I need a table called Service, where is it shown on the documentation?
3) "I need to add a column with a foreign key to service named reservaton_id, how does this documentation says it?
For all this steps above, create the correspondent migration file as you normally have done.
The main difference here is not to run the migration locally. Instead, push your new version app to your heroku remote branch and there you run the migration, like:
heroku run rails db:migrate
Remember to not run this same migration locally because you already have these tables locally.
The last two advise is:
1) If your migration doesn't go as you expect, don't delete the migration file. Instead, run rails db:rollback and try again.
2) Keep tracking your migration files on the same branch of your version control.
I have made quite a large upgrade to my app. I have older version deployed on Heroku at the moment. Problem is that I have added/removed quite few migrations in the process of making my app more modular. I do not want to lose my registered user table that is already up on Heroku while deploying the update. Are there any tips someone can offer on how to preserve my user table while upgrading the app? I do have backup add-on installed but I have no clue what to do with that file.
You should then setup your migrations more carefully since that one, which is last presented on the heroku server. So, when:
you are adding a column, just setup defualt value
you remove the column, you shell export data to (for example) YAML, and store it in the tmp/.
you are reconstructing parts of the colunms by adding and remove some of them, in migration carefully copy required data from older column (prepared to deletion) to newly created ones.
If you're that concerned about deploying I think you might need to declare migration bankruptcy.
Create a new migration that drops the current schema and copy the new database schema into it
Dump out the contents of your database as CSV ( https://coderwall.com/p/jwtxjg/simple-export-to-csv-with-postgres ) or using Rails to dump in some other way (YAML etc.)
Write a Rake task to parse the data dump into your new schema
Set up a new database on Heroku Postgres (this does not delete the old data)
Do a dry run locally to make sure it all works
Promote the new database to DATABASE_URL
Deploy, migrate, run the Rake task
Not very nice and not something you can roll back from easily if it goes wrong.
I have to do a lot of conditioning of the data that will seed my rails database. This is a one-shot activity before deployment, never used after deployment, but I want to keep the programs I use for it within the projects configuration management (mainly for the sake of an audit trail for where the seed data came from).
Where is the canonical place in a Rails app for such support files that don't form part of the application?
Seed data should go in db/seed.rb. You can learn more about seed data in the docs.
The problem with adding all these items to your repository is that not only will it make the checked in code large, also you will have to clean the code each time after deploy.
I do not think such items should be checked in. Personally, I place all such items in public data, upload it for first deploy and then next deploy will no longer have this folder as the deployment using capistrano will not link to the data folder anymore.
This way the data can stay in the shared folder on the server should you need it again but not in your repository.
I currently exclude my development.sqlite3 from Git so that I can keep my git status clean unless a file has actually changed.
However when I want to checkout a much earlier version of the code that relied on a different database (and dummy data) from an earlier time I end up with code and a database that are out of sync.
Because I don't have my dev database checked into Git it's very difficult to reset that environment. I can't just rebuild the database because it needs all of the dummy information in it.
Is there a happy medium whereby I can automatically back my database up to Git on a daily basis (or perhaps each time a tag is created) but can also still exclude it in Git .ignore?
If there is data you require for the database to function correctly or dummy data that helps you to develop then I think you should be using a seed file to define them. Then when you check out the previous version you run the migrations first and then:
rake db:seed
If you update your seed file as you go to reflect the state of the database then whatever revision you check out you'll be able to generate the correct data.
Firstly, Happy New Year everyone.
I'm new to Rails, so please tolerate any incorrect use of terminology...
I have developed a simple Rails application, backed by a MySQL database.
I would now like to deploy this application to multiple, independent groups of users (i.e. it is a club application, and I would like to deploy it to a number of completely independent clubs).
I would like to use the same Rails Application code as much as possible, and just have a separate instance of the database for each club.
As each instance will be running on the same server (until server load proves to be an issue) I assume I can use a different port for each Rails server to steer users to the correct group?
I'd read that there are test and production modes, is it possible to have multiple [additional] instances of production modes, e.g. club1, club2, all sharing the same code, with unique databases?
My questions are how to support multiple separate database instances, and also how best to route to these?
Any advice on how to go about this much appreciated.
If you are using Git (I suggest you should be!) then you can keep a central version of your code in one place and then deploy it multiple times, changing only the database.yml file (it should not be checked in to your git repository in that case). http://git-scm.com/
Let's say you put all of your code up on github.com with username 'snips' and the project is called 'clubster'. Using something like Heroku you would then do:
git clone https://github.com/snips/clubster.git
cd clubster
heroku create boxingclub
Because Heroku auto-configures your database there is no need for a database.yml file
git push heroku master
And you'd have a version of your code deployed at boxingclub.heroku.com
When you make changes to your code you just go to each of your installations and do:
git pull origin master
git push heroku master
Which updates your code on that particular instance of your application.
And if you're getting a little more advanced you'd be looking at Chef to manage the whole setup for you. http://www.rubyinside.com/chef-tasty-server-configuraiton-2162.html
The other approach would be to have some kind of subdomain system, but I'll leave that to others to cover.