So for a class I have to turn in my Rails application to my professor. What is the best way to make sure everything goes smoothly when he trys to start it up? Also, is there anyway I can freeze a database and send that with it so he has all of the data I have been using in the application?
Thanks a lot.
Depending on your needs, the SQLite3 database (used by default in Rails) is stored on the file system in the db directory of your Rails app. So, assuming your professor has the requirements to run Ruby on Rails, the application will start up with the data you've used.
My guess is you have hard coded connection strings in your rails application. Ask your professor what server he will be running it off of. At that point either change the strings to match or create a config file that is read in and can be edited (which is the better choice of the two). Most databases have export functionality which will allow you to export the current information within the database.
Related
I use Aiven.io to manage a PSQL server, inside has multiple databases! Im using it from my rails app, so my rails app uses xxx_production, xxx_development etc.. But i dont remember creating xxx_optimization or metrics databases. The metrics one in particular is 50GB (My xxx_production is only 11GB so this is costing me a lot of extra money)
Is there any way to figure out who created these or why? My suspicion is there is some GEM im using in my rails app that could have created it to keep track of things? No idea what these databases are, and i would delete them but I do want to know what they are so i make sure im not breaking anything.
Thanks!
Say I have a running rails project, and now I need to add entries to its database from an outside source. This is to be done automatically once a day and can be reduced to loading data from a text file.
Now I'm wondering, what is the conventional way to do this in a Rails project? Do I create a controller method which runs once a day and how do I call it? Do I access the database from outside with something like the sequel gem?
I think it depends of your application restrictions and business requirements.
My opinion is that both ways are good.
But I'd prefer to connect directly to database of use some message queue, just to avoid HTTP, to decrease number of HTTP calls.
I have a Ruby script that downloads web pages containing financial statements for publicly traded companies, scrapes the pages for essential financial data, processes the financial data, and writes the results to a Postgres database.
I looked at the procedure for creating a Ruby gem at http://guides.rubygems.org/make-your-own-gem/ , and I'm considering making my Ruby web-scraping script a Ruby gem. Unlike the Hello World exercise in the example, my script needs a Postgres database ready to go.
I am working on a Rails app (Doppler Value Investing) that displays the stock parameters. Having a Ruby gem that nicely integrates into my app would be smoother and more elegant than the setup I would otherwise use. (At the moment, I have a separate Ruby app that does the scraping work and writes the results to the Postgres database.)
The one hitch I can think of is the need to manually create a Postgres database first. Is there a way to programmatically do this, or do I simply need to include in the README a statement that says something like "You MUST create a Postgres database with the name *db_name*, or this gem will not work"?
Just include the instruction in the README. Apart from anything else, you can't know ahead of time what privileges the user of your gem is going to have, so you'd have to deal with not being able to create the database programmatically anyway. It's a one-time task, so automating it doesn't make a huge amount of sense.
Once the database is set up, creating the schema automatically does make sense.
I'm trying to install Rails (On Mac OSX) and I basically have it all done now, but I'm currently learning from a book that uses SQLite 3, I just want to use MySQL, will the statements for talking to the Database be the same throughout the book? Also, when you set your Mysql password/username you do so in /config/database.yml but that's visible from the web, and anybody can navigate there and see my password and what not, is there something I am missing here?
ActiveRecord will abstract any interaction with your database. As long as you use it you don't have to worry if you are on SQLite or MySQL.
The only public facing folder is the public folder. This contrasts with PHP applications where everything is exposed (and must be exposed in order for the web server to interact with it).
I have a Rails app and a Sinatra app, sharing the same database. The Sinatra app uses ActiveRecord.
Can I run migrations from within each app, as if they were in the same app? Will this cause any problems?
The schema.rb file in the Rails app tracks the current migration via
ActiveRecord::Schema.define(:version => 20121108154656) do
but, how does the Sinatra app know the current version the database?
Rails 3.2.2, Ruby 1.9.3.
The version column in the schema_migrations table equate to the time stamp on the front of the ruby migration file example: 20130322151805_create_customers.rb So if two ore more applications are contributing to the schema_migrations table roll backs will not be possible if rails can't find the down() method (because it will not find a migration file contained in another app ie db/migrate/...)
I have a current situation that is exactly this and I have opted to have a master ActiveRecord app that manages migration and data conversions as our database evolves. Keep in mind that part of the deal is to keep models up to date as well. This has been time consuming so we are considering breaking apart the DB in to business domains and providing APIs (JSON) to query support data for another application. This way each application manages it domain and is responsible for exposing data via API.
regards.
If you connect both applications to the same database you should be able to run migrations on it but I strongly suggest you use another option since you will almost surely hit a wall at one time or another:
split the database in two if possible with each application responsible for its own database /migrations.
have one application considered the "master" database and use another database for the data specific to the second application but make it connects to both database (each application still only apply migrations to one database)
If you need to share data between multiple applications another option is to implement a REST service in one and use it on the other, you can have a look at the grape gem for a simple way of doing so.
Edit: I realize I forgot to speak about the activerecord migration, there is no longer any "version" of the schema, what activerecord does is that it read all your migration filename, extract their identifier (the starting part) and check if they have already been applied so in theory you can run migrations from two applications on the same database provided they don't interfere.
But if both migrations act on the same tables you will almost certainly run into big troubles at one point.
I disagree with Schmurfy, even if his presented options are valid, its a bit of an overkill to share data through REST (granted, its pretty easy to implement with ruby / rails).
If your case is simple you could just use one database from both apps, and since you use AR in both of them you have no problems with versioning, AR takes care of that.
Also i dont know what happens if you run db:migrate from both apps simultaniously if you use a inferior dbms like mysql which does not allow DDL in a transaction, certainly nothing good..
Also it would bother me to look which app needs what column and not have the migrations in one place. You could use a shared repository to manage the migrations from both apps.
Rails migrations store current database version in schema_migrations table in the database. So both of your apps will be able to check the current version.
The version numbers are timestamps, so there shouldn't be any problem with duplicate values, as it'll be almost impossible to generate two migrations at the exact same millisecond. So you should be fine here.
The only problem I see is that when you rollback a migration in one app, it'll set the db to the previous known version and I'm not sure if it will pick the previous one from the db (which could be from the other app), or the number from the previous migration file. You may want to test that scenario to make sure.
I decided to put all migrations in the Rails app because:
Since there is only one database
Rails manages migrations
This has worked well.
This simplifies the system because all migrations are stored in one place. And, the Sinatra app doesn't need to know about them anyway.