PG gem behaves strange. It requires live DB connection to only generate a model. How to turn it off?

I used MySQL as a backend before. Now I had to move to PG since Heroku doesn't have MySQL and forces everyone to use their Heroku-PG database.

But PG virsion of Rails works diffidently. I cannot generate a model without PG server running:

C:\ruby\Heroku\App>rails generate model Products

C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/activerecord- 3.2.13/lib/active_record/connection_adapters/postgresql_ada pter.rb:1216:in `initialize': could not connect to server: Connection refused (0x0000274D/10061) (PG::Error)        Is the server running on host "localhost" (127.0.0.1) and accepting        TCP/IP connections on port 5432?

I even couldn't open Rails start page (Welcome aboard, I mean) without database and app_development table in it being created! I had to explicitly create them before.

How to turn off this behavior of PG? I don't want to start PG server every time I just need to run some rails|rake task. This totally not the same as MySQL. I didn't need MySQL server running to call rake|rails tasks.

I used MySQL as a backend before. Now I had to move to PG since Heroku doesn't have MySQL and forces everyone to use their Heroku-PG database.

Not really. You can run MySQL locally and use PG on Heroku.

But PG virsion of Rails works diffidently. I cannot generate a model without PG server running:

C:\ruby\Heroku\App>rails generate model Products

Maybe it's a Windows thing? I ran that exact command in a test app with PG not running and it was fine. Trying to access the model in a console expectedly threw an error.

How to turn off this behavior of PG? I don't want to start PG server every time I just need to run some rails|rake task.

Why would you start and stop it at all? If that's what you're using, start it at boot time and forget about it.

FWIW,

Hassan Schroeder wrote in post #1107485:

Not really. You can run MySQL locally and use PG on Heroku.

I prefer to use raw sql anywhere where it not possible to use Model.find or Model.where. So it is quite a problem for me to separate server and local versions.

Maybe it's a Windows thing?

Agree, maybe. They say all rake and rails tasks are so slow only on Windows. So it can be the reason.

Why would you start and stop it at all? If that's what you're using, start it at boot time and forget about it.

I have batch files that create a specific DB environments only when I run them. It is more convenient to me.

It is not a big problem with PG. It was a little unexpected after MySQL.

Wins Lin wrote in post #1107488:

Hassan Schroeder wrote in post #1107485:

Not really. You can run MySQL locally and use PG on Heroku.

I prefer to use raw sql anywhere where it not possible to use Model.find or Model.where. So it is quite a problem for me to separate server and local versions.

While there may be some circumstances where it may be necessary to wrote raw SQL, doing so should be extremely rare. Arel (which the where method derives) is a very powerful query language and AFAIK can do practically anything that SQL can do. One major advantage of using Arel is that it produced database agnostic queries.

I generally design my applications using SQLite in development, then choose a production database based on my deployment needs. I make every effort to create database agnostic code.

Maybe it's a Windows thing?

Agree, maybe. They say all rake and rails tasks are so slow only on Windows. So it can be the reason.

Why would you start and stop it at all? If that's what you're using, start it at boot time and forget about it.

I have batch files that create a specific DB environments only when I run them. It is more convenient to me.

Sounds to me like you put great effort into making things less convenient for yourself. Like developing Rails in Windows, using database specific SQL embedded into your applications, etc.

It is not a big problem with PG. It was a little unexpected after MySQL.

I find it extremely convenient using SQLite for development, on a UNIX based OS, and having the flexibility of choosing whatever database I want when it comes time to deploy my applications.

But, to each his own I suppose.