I'm currently developing my Rails app on my local machine. I have no DB installed on my local machine, and I'm sending my codes to remote testing server which actually runs the app in development mode.
Until yesterday all commands like rails g model foo or rails g controller foo on my local machine worked with no errors.
But now all of rails generate commands started to fail due to no database connections. I think the direct reason is because I made some changes to my app configs, but I'm not sure where the changes are.
I guess the wrong part is that rails generate commands are always invoking active_record
which always verifies the DB connection.
Now, my question is:
Is there any way to temporally disable rails to verify the database connections, for local development(which has no DB connection available)?
I tried removing config/database.yml but it didn't help.
Your local development environment needs to have the same sort of facilities as the application requires. If you have database backed models then you need a database, preferably the same one as used when deploying the application so your tests are useful.
It really shouldn't be a big deal to set up a database for local development. Depending on your platform there are usually many different easy to use installers available.
Uploading your code changes to a remote server for execution is a really dysfunctional development model. If you have no alternative, it might be best to create the models on the remote system and pull them down to edit.
Related
I have a database that I created and populated using the development environment in Rails 3.2. I deployed the database onto a server using git and phusion passenger. Currently the server is still running the development database because it is the one that is populated. I have 2 questions:
1) If I switch the server to the production environment, will all of my data transfer over? If not, how to I transfer the current data into the production database?
2) If I push updates to the server from my personal machine using the development database, and the server is using the production database, will all of the data that has been inputted into the production database by users stay in tact? or do I have to configure it to not erase data when I pull my project to the server from git?
For the first question:
If you change the environment to production, it will use the database which is configured in config/database.yml file. You can take a backup of the development database and import the backup file if you want to use the same database in production.
For the second question:
By the term push updates to the server from my personal machine, i assume you are talking about code changes being pushed and not any db related things. pull/push operations with git will never affect the way you interact with database. The data from users in production db will remain intact.
1) If I switch the server to the production environment, will all of my data transfer over? If not, how to I transfer the current data into the production database?
It will not generally by default. The database.yml file has a group for development, testing, and production. Development and Testing will tend to be local, and production (hopefully) is not going to be on your local machine.
2) If I push updates to the server from my personal machine using the development database, and the server is using the production database, will all of the data that has been inputted into the production database by users stay in tact? or do I have to configure it to not erase data when I pull my project to the server from git?
The actual data should stay in tact, however, remember to make your migrations compatible with the data that is up there. One big thing to watch out for here is adding a mandatory field to an existing table without dealing with repopulating earlier records. This will break your deployment.
You can get the database from production/send it back by using your environment's resources (I think Heroku uses pg:dump).
WRT your comment on GhostRider's answer, are you using the production DB remotely from development?/Where is your deployment? What does your database.yml file look like? (remember to not include your passwords :D, I will update answer on reply).
I'm very new to Rails.
I am confused about the development and production databases. I am using postgreSQL for all of my environments and heroku to host the site. I am able to push migrations and seeds to my production database on heroku. However I entered quite a bit of new data through the browser on localhost:3000. I spent a long time trying to figure out how to get that data to heroku but finally was successful by destroying then creating a new empty database and pushing my development database to it. Now my site on heroku is the same as localhost:3000 using rails server. I modified the database.yaml file so that the development and production databases are now the same name (the name of the development database). But I don't think that means that if I make changes to the development database through localhost:3000 they will automatically be changed on the heroku site. I am very confused about the colors (CRIMSON, MAROON) on heroku - are those different databases than what I specify in the yaml? And I don't know whether I should now be entering new data on the localhost:3000 site or the heroku site. Sorry if this is very amateur. Thank you.
You're getting confused with how Rails uses Databases
Let me explain:
Rails uses the MVC (Model View Controller) programming pattern to populate your applications with database data. Rails uses this pattern because it's the most efficient & extensible, and it works by taking a command from a user (clicks a link, inputs data), sends to the controller & performs the request on the model
The way all rails applications work is to take commands (which you define), and perform database operations with them & then repopulates the app with the new data
Rails is designed to work with a single database, and the database.yml file is there to specify which database that is (it's good practice to have different databases for development, staging & production -- for performance, efficiency & other issues)
This means that the database name is not important - what is important is to keep both databases up to date using the rake db:migrate system to give all databases the required columns to make your app work properly
In answer to your question, the data you have is going to be different for development & production. Your production environment is meant to be that "holy-of-holies" where everything is compiled & running efficiently
The production environment is meant to handle its own data, and should be populated through your application. The reason for development & production databases is to ensure you can "get things wrong" in the development environment before you try and apply it to the production db
If you tell us some more about your specific issues, we'll be able to give a much more refined answer
I want to migrate a database to Heroku. The old database is exported to some JSON files, but now I don't know how to select the database in Heroku.
My issue is:
The data is always increasing, so in the future, there will be a lot of data. Which database is available for this?
I can only get JSON files from my old database. Can it be imported into the Heroku database?
My users are mostly in America. The database in Heroku whether lead the user's access speed slowly or not?
My project is using Ruby on Rails.
What should I do?
First of all, Heroku provides PostgreSQL as the default database. It might be the following reasons for use it.
PostgreSQL is a powerful, open source object-relational database system.
Heroku Postgres is the SQL database service run by Heroku that is provisioned and managed as an add-on.
Heroku Postgres is accessible from any language with a PostgreSQL driver including all languages and frameworks supported by Heroku: Java, Ruby, Python, Scala, Play, Node.js and Clojure.
For more you can refer this http://www.postgresql.org/about/advantages/.
It's better that you specify the database you currently use for your application. If you give more information, I will update my answer.
But firstly, reading the article Moving a Rails App to Heroku will help you a lot with moving the application to Heroku.
Heroku has addons from another provider. The only database they provide is PostgreSQL which is very nice and suitable for many kind of applications. It's just brilliant.
Read the mentioned article above.
If you create your application in Heroku, it will be located in the USA by default. I don't know if Heroku optimizes to the location of your application and addons or not, but normally if you have something slow in your application, it's your fault, not Heroku's.
Yes! Heroku loves Ruby on Rails
I want to write a few unit tests that do not make any changes to a database.
I have a Rails 2.3.11 application. This app has a SQLite database as its primary database. In many ways, this is a run-of-the-mill Rails app.
What makes this app unique is that it also establishes a connection to a SQL Server database. I have some models which are abstract classes and they use the SQL Server database. I have before_save and before_destroy callbacks to prevent any changes being made to the SQL Server database. Also, the user credentials to connect to SQL Server are supposed to be read-only.
I would like to write unit tests that make assertions on the data that is already present in the SQL Server database. But I don't want to setup or teardown the SQL Server database.
I am afraid to just see what happens. I would like to have a setting in the unit test that will prevent Rails from trying to setup or teardown the SQL Server database. Is this possible? How do I do it?
Thank you!
The setup/tear down only affects the application database (SQLite, sounds like), not additional, external database connections.
Also, you should keep your test environment completely separate from your production environment. So, if you're using a test SQLServer DB as well (and you should be, with test data in it - not the production one) then you should be fine even if the worst happens.
I'm very new to web programming (or actually, very old to it, since the last time I messed with the web was HTML 1.1), but now need to deploy a web application quickly. It seems like every time I turn around, there's new acronyms and technologies to learn (JSON, XMLRPC, GWT, Javascript, Rails, etc).
Here's what my app must do:
Given a username and password, authenticate (easy enough, everything does that, apparently).
Allow the user to upload a large glob of data for processing.
Process that data.
Allow the user to download their processed data.
I've already got Java scripts and a database for handling the data. On one machine, I can run a series of command-line programs to process an incoming datablock and put the results back into a mysql database. That is already present and working.
I want to construct a web front-end to this task, using these existing and tested methods. I'm currently leaning to this approach:
Have two machines, a database machine and a web server. That approach allows for later scalability, if necessary, but also requires that I can't assume that the programs that I use to access the data and manipulate it are locally stored.
Use a Ruby DRb application to create a server and a client. The client would pass data to the server which would in turn call these applications.
Use some other Ruby interface to interact with the DRb for the web frontend.
Here's my problem: it looks like most Ruby applications for the web automatically try to build some kind of local database. All the Rails tutorials I've found start with making your own database and interacting with that, which is exactly what I don't want to do.
Is Rails the right technology for me, or using Ruby DRb? Is there some other technology I should be exploring?
If Rails or Ruby is the Right Thing here, what should I be looking at? I already have the Programming Ruby book, and have used that for some of the backend stuff as well as getting basic DRb stuff working.
Sounds like Rails might be a bit heavyweight for your situation. Perhaps Sinatra might be a better fit? It's an ultra-lightweight framework: a hello world app might look something like:
require 'sinatra'
get '/' do
"Hello World!"
end
Rails is fine. You can have development and test databases on your local machine and the production database on a remote machine. It doesn't have to be the web server. Get a copy of Agile Web Development with Rails. It'll teach you all you need to know.