Rails and SQlite3 - Migrations from SQlite3 to PostgreSQL - ruby-on-rails

I am learning RoR using M Hartls Rails tutorial book. I am very much new to the world of databases. I created the application(simple one, just on 3rd chapter) and did my RSpec and made few static pages. I wanted to migrate from sqllite3 to postgres.
I changed the database.yml to postgres deleting the full sqlite3 specifications. Now I run my app it does not work? It says 'PG:' Error.
I need to first understand how the data is stored in sqlite? I searched the db directory and I could not find the development.rb or any database file (probably because I altered the database.yml file)
In this case, I did not enter any data as such,(it still does not work , gives me error) but generally, where does the data get stored? and since I changed the database.yml file to postgres, what will happen to the existing data?
what does rake db:migrate command do?
It would be great if someone gives a simple analogy or explanation is to how this is stored then finding a solution for this problem becomes much easier.

sqlite stores its data in files in a folder on your filesystem, using its own system of storage.
postgres will do a similar thing, but in a different folder, using a different system.
You will generally never touch these folders. You don't need to know where they are or how the dbms (database management system, eg sqlite or postgres) stores the data. All your interaction with your dbms will be done either via the terminal, or the dmbs's shell client (which you launch in the terminal aka the shell), or via a desktop client, or via your rails app's own connection with the dbms.
When you make a new rails project you need to create the database it will use. If you switch to using a different dbms then you will need to create a new database in that dbms for your app to use. Google how to do this.
If you have data in one dbms and you want to bring it into a different dbms then you will need to export it from the first dbms and import it into the second dbms. Google how to do this.
rake db:migrate will run any migrations which haven't been run in your current database (ie the one in your database.yml). Rails creates a table in your database to store which migrations have been run already: this is how it keeps track. It will fail if you haven't created the database yet.

Related

Access to database tables location created with migrate in Rails

I did a homework on Rails using RubyMine.
I need to submit the homework with the database tables . But I can't access database tables file location, because I don't know under the which folder I created with migrate. I have migrated tables at the rubymine terminal
I used postgresql for database.
I will be so happy if you could help me. Thank you from now.
There is a schema.rb file that represents your database under db/ folder. So this is the answer for your first question.
The answer to second question is in order to deploy your code on a different computer, the third-party softwares need to be installed. In your scenario, this third-party is postgres as db server. To deploy your code, just type on your terminal rake db:setup. This command will create your database, run migrations and finally seed your database if db/seed.rb contains something. As a result, after rails s there should be some output.
It is worth to note that Rails is db agnostic framework. If you did not use postgres specific features then you would use mysql or sqlite on different computers/servers. But keep in mind that you should change the adapter from config/database.yml if you want to use another database.
Ödev sunumunda başarılar.

Can I deploy to Heroku without destroying existing database? Ruby on Rails

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.

Rails -- working with an existing db, cannot run migrations without losing data

I am a beginner working with Rails 4.1. I am trying to integrate an existing sqlite3 db with my app in the development environment.
To try to get this to work, I've followed the steps listed at Joel Berghoff's blog (for MySQL):
Reference the db in config/database.yml
Run “rake db:schema:dump”
Convert schema.rb into db/migrate/001_create_database.rb
The issue I am facing is, whenever I run "rake db:migrate" the entire db refreshes and I lose all the pre-populated data. I got around this for awhile by running migrations first, then replacing the blank db that was generated with my pre-populated copy -- this allowed me to play around with my models in the rails console and see the data. However when I try to boot up the server on my local machine, I get a message that migrations are pending.
I am not quite sure what to do here...I've read that I should be seeding the db from "rake db:seed", but my existing db is quite large -- almost 1mm records, and when I attempted this (in albeit clumsy fashion) it ran for over 3 hours before I gave up. Any guidance on how to proceed is much appreciated!
Migrates should be used to create and changes the tables and fields, not load data, as you can see here Ruby on Rails Guides
If you want to import data you could do it on the seeds, but in your specific case it seems to me that you should create a dump from your origin database and load it on the target database.
Here is a tutorial sqlite3: how to import/export data from/to a file
sqllite3 and MySQL are different things. My guess is you think you are connected to sqllite db but in reality you are connected to an empty MySQL db.
Look into ActiveRecord migrations.
Here is a rails doc on ActiveRecord Migrations: http://guides.rubyonrails.org/migrations.html

How to handle local databases for rails applications and errors after rails project install

So I am starting to learn rails, with a php and front end background. I created a new rails project and that was going well enough, until I downloaded another rails app off github and installed all dependencies and gems...anyway these problems have been my undoing for the last two days...I would really appreciate some clarification.
How exactly do you manage local databases for a development version as opposed to those external databases for a live version?
Will Rails build a local database automatically after an application is imported from Github for instance? Or does one have to be created manually, also should it have the same authentication credentials that the downloaded uses to talk to its database?
Also, after I downloaded PostgreSQL and its gem, I can no longer start rails server for my old rails project, or for my new one for that matter, both get these errors:
gems/actionpack-3.0.16/lib/action_dispatch/http/mime_type.rb:98: warning: already initialized constant PDF
gems/activerecord-3.0.16/lib/active_record/connection_adapters/postgresql_adapter.rb:950:in `initialize': FATAL: role "postgres" does not exist (PGError)
Since you're using postgresql (which possibly shared by several applications), and in my understanding, two rails applications usually do not share namespaces other than database, I guess you've not modified config/database.yml file.
By convention, the default development database name is development, so, if you haven't touch the configuration file, the two applications share same database options, cause conflicts.
I usually modify the database name to development_SomeApplicationName (replace SomeApplicationName with some meaning application name to differentiate database name) just after creating new application.

porting and backing up databases

I am using sqlite3 in development and mysql in production on a Rails 3.2 app.
I'd like to be able to backup the mysql, and also to create a sqlite copy of it for use in the development environment. Anyone know how to do this, or the preferred way to back up mysql at least?
I'm partial to this one, and use it to convert to/from MSSQL, sqlite and MySQL quite a lot:
https://github.com/unixmonkey/rails_db_convert_using_adapters
This may not be feasible if you have a large DB, but I am working with a rather small one (about 10MB).
(1) I back up all of my model classes into a .zip file using a rake task, and then
(2) have a button (with admin authentication) that runs another rake task to reload the data.
So I can backup the data in dev/prod mode, push my files to the other environment, and reload the data from backup (it's in .csv files, so it's DB-independent). This worked for me switching between sqlite3 and mysql2 (I am using Rails 4.0.1 if that's relevant).
I can post code if that would be helpful to people, but it's a little messy so I'll save the eyesore unless someone would find it helpful. I've found the .csv into .zip file backup to be a nice workaround for different SQL systems, if you're working on the order of megabytes.

Resources