On Fri, Dec 11, 2009 at 3:50 PM, Joshua D. Drake <jd@xxxxxxxxxxxxxxxxx> wrote:
Fair enough. I'm of the opinion that developers need to have their unit tests run fast. If they aren't fast then your just not going to test as much as you should. If your unit tests *have* to createdb then you have to do whatever you have to do to get it fast. It'd probably be better if unit tests don't create databases or alter tables at all though.
Regardless of what is going on on your dev box you really should leave fsync on on your continuous integration, integration test, and QA machines. They're what your really modeling your production on anyway.
On Fri, 2009-12-11 at 15:43 -0500, Nikolas Everett wrote:My experience is that bad dev practices turn into bad production
> Turning fsync off on a dev database is a bad idea? Sure you might
> kill it and have to start over, but thats kind of the point in a dev
> database.
practices, whether intentionally or not.
Fair enough. I'm of the opinion that developers need to have their unit tests run fast. If they aren't fast then your just not going to test as much as you should. If your unit tests *have* to createdb then you have to do whatever you have to do to get it fast. It'd probably be better if unit tests don't create databases or alter tables at all though.
Regardless of what is going on on your dev box you really should leave fsync on on your continuous integration, integration test, and QA machines. They're what your really modeling your production on anyway.
