0

Saw How to customize Gemfile per developer?, but it didn't really do what I want and it is old.

Use case: I want to use Postgres and other developers are using SQLite.

One solution is to modify my Gemfile and not commit it, but then it will be out of sync if anyone makes any changes to it. And it will get accidentally committed after a while anyway.

Is there a clean way to remove the SQLite gem and add the Postgres gem in my environment, without affecting other developers' environments and other gems in the Gemfile?

FWIW, these changes only affect development and test environments. Not staging or production.

Or, perhaps it isn't necessary to change the Gemfile at all. Is it possible to install both gems and switch on the db config file? If so, how to set up a per-developer db config?

EDIT: Changing the Gemfile is not necessary. Just install the pg gem and change database.yml config file.

Community
  • 1
  • 1
B Seven
  • 44,484
  • 66
  • 240
  • 385
  • 2
    I would wonder why you want to do this at all. I don't know if there are differences between SQLite and Postgres (specifically in the SQL generated) but it's a risk. Developers should all be using the same environment as much as possible to remove inconsistencies. – MrDanA Nov 08 '12 at 15:01
  • 1
    There are differences between SQLite and postgres, even if the generated SQL is the same some things behave differently just because the goal of SQLite is not the same as Postgres. I think one of the differences (not entirely sure) is that SQlite only has one internal type: string and everything is translated to and from it. – Schmurfy Nov 08 '12 at 15:07
  • Actually, that's one reason I want to run Postgres locally (that's what we use in production). But I don't dictate what other developers do. – B Seven Nov 08 '12 at 15:18
  • 1
    Well I'd have to say that then you should change everything to Postgres, and then let the other developers wonder about how they can use SQLite. And then tell them they should just use Postgres. There's no good, practical reason they shouldn't. Although you may not want to dictate to them (I get that), the end goal is to make good software, and that's not possible if everyone is developing with different technology when they shouldn't be. – MrDanA Nov 08 '12 at 15:55

3 Answers3

3

The correct approach for your case is to include all gems used by any developer in the gemfile and have a separate database.yml file per developer. You can simply leave database.yml as non-source-controlled, and provide a sample config file (database.yml.sample) for developers to copy and modify to their environment as needed.

As others have pointed out, using different databases among developers is not very good practice as these differences can have unintended consequences in the non-original environment. In a case where you need to support multiple databases, this may not be a bad idea, but in such a case, each developer should have access to all the target database systems so that across-the-board testing can be done by everyone.

PinnyM
  • 35,165
  • 3
  • 73
  • 81
2

It's really not a good idea to run a different database than other developers and especially not compared to the production system. The idea is that your development environment reflects, as closely as possible, the software employed on the deployment target.

There are occasions where having support for multiple databases is required because your product is deployed on many different databases. It does not sound like this is the case here.

If you use Postgres you cannot be assured your new code will work with SQLite at all.

tadman
  • 208,517
  • 23
  • 234
  • 262
1

Humm, it is not very adviced to do so, since development must mimic as best as it can the production environment, so to develop in two db engines... tricky. Anyways, your only contraints are the database.yml file and the db adapters. You should not share your database.yml file with the other developers, as PinnyM already said, but you should also remove the db adapter gem you are using from the Gemfile.

Add this to your your Gemfile:

group(:production) do
  gem "sqlite" 
end

and you'll have an adapter configured only in production. Don't forget you'll also need a database.yml for it. That's why it is tricky to do so. Or just set the db settings manually (database.yml just gets parsed for this step, but that doesn't mean you cannot do it in plain ruby).

ChuckE
  • 5,610
  • 4
  • 31
  • 59