3 ms·

Why do you want SQLite for development? Running Postgres on your dev machines is a docker one-liner that you can put in the README.md for your devs to copy past

Why do you want SQLite for development? Running Postgres on your dev machines is a docker one-liner that you can put in the README.md for your devs to copy paste. Most sane CI services also offer Postgres.

always_good 9y ago
I cringe at the thought of using so few features of Postgres that you can actually use Sqlite.
- _rami_ 9y ago
  Me too, at times. Django makes it bearable though, and going forward we'll probably use more advanced features of PostgreSQL in places where we can fail gracefully or fall back to simpler behaviour on other databases.
  - mattmanser 9y ago
    I honestly feel sad for your colleagues, from your comments on this thread it sounds like you've made a very unnecessarily complicated, over-engineered, nightmare of a process they have to suffer through. Everything's got a justification, and the justifications suck. Use postgres, or don't. Having a stupid number of slow tests is the problem to fix, the solution is not limiting your developers to using basic SQL.
    - _rami_ 9y ago
      It certainly is a future perspective for us, moving to all-postgres, but forcing every installation of pretix (an open source application) to go through this migration is not something we'll do overnight ;)
    - foota 9y ago
      Please be civil.
shlomi-noach 9y ago
Agreed, and having some experience with both MySQL and SQLite, running SQLite in testing cannot cover problems you'd find with MySQL (e.g. SQLite is so limited with concurrency that you cannot use it to confirm concurrency issues will be dealt with in your production MySQL). I would assume the same holds for SQLite<->PostgreSQL.
- _rami_ 9y ago
  Sure, there are often problems differing between the databses. Our Travis CI configuration runs our test suite against all three different databases: https://travis-ci.org/pretix/pretix/builds/351704035 https://travis-ci.org/pretix/pretix/builds/351704035 However, having SQLite at hand for local development/testing makes things easier. In my experience, real-world concurrency issues (that you are talking about) are always hard to find in manual/automated testing, or do you have a good strategy of trying that?
  - shlomi-noach 9y ago
    > In my experience, real-world concurrency issues (that you are talking about) are always hard to find in manual/automated testing I agree, and I don't have a good, generic, strategy for that. I didn't give the best example.
ubernostrum 9y ago
Depends. For apps that I distribute generically for use with Django, I usually stick only to ORM features that are supported across all backends. And then I just have tox set up to run the tests with an in-memory SQLite database, since that's fast (and Django's test suite already exercises its ORM on all the backends, so I can trust the ORM will work on other DBs). My personal blog, though? I run Postgres locally on my laptop (via Postgres.app) to make the dev/testing environment as similar as possible. Most places I've worked have done similarly, running either Postgres or MySQL locally, and I have run into bugs that only manifested on MySQL (not because of bugs in Django, but because of MySQL acting in the way MySQL acts).
_rami_ 9y ago
Our development setup currently does not need Docker at all. In fact, it does not need a lot more than git and a recent Python version: https://docs.pretix.eu/en/latest/development/setup.html https://docs.pretix.eu/en/latest/development/setup.html I agree that this is an opinionated setup and I do see the value of a development setup that mirrors production closely. (1) During testing, in-RAM SQLite databases are really fast and well capable of running tests in parallel. We have a test suite of ~2000 tests that currently needs ~4min to run on a modern notebook with four threads, so this matters. (2) pretix is an open source project. If we'd only have a small number of developers in an in-house team, I wouldn't care at all. However, there are many people contributing small and large features and fixes to pretix, and many of them are drive-by contributions: People fixing a problem they just experienced and then leaving again. I want to make it easy for these people, even if they use operating systems where installing Docker first might be a hoop they do not want to jump through. That said, deprecating MySQL at some point would also force all self-hosting users of pretix to go through all the steps we did here, so this wouldn't be viable in the short term.
- _rami_ 9y ago
  I may add that our development setup has no external service dependencies, redis is optional as well. Of course, we wouldn't recommend that in production, but we're kinda proud that it's possible.
- fovc 9y ago
  2000 tests in 4 minutes actually sounds really slow. We use postres and our Django tests run at roughly 9000/min on 3 year old laptops. Start your pg container once and use Django's -k flag when running tests to avoid start up times. We also take care to separate DB access from business logic and to unit test those separately.
  - _rami_ 9y ago
    Sure, the main reason for this is that nearly all of our tests touch the database and operate on a comparatively high level, we have way more things in a fuzzy category between functional and integration tests than actual unit tests. This is of course a flaw in our test writing, but it's what we have right now ;)
audiolion 9y ago
Agreed, I originally did this and the first time I ran into a prod bug because sqlite and Postgres differ in implementation of some more advanced methods I immediately moved off it and never looked back. A lot of people stick with sqlite in dev because when you start a django project it will default to that. Even if you dont use Docker, brew install postgresql is just as simple. The commands to setup a user are like 3 lines. 20 mins of doc searching and one time README setup.
- nh2 9y ago
  This doesn't need docker and not even 20 minutes. initdb -D mypostgresdatadir # creates the DB postgres -D mypostgresdatadir -p 1234 # runs DB on given port Done. On systems like Ubuntu, these binaries live in e.g. `/usr/lib/postgresql/9.5/bin/postgres`.

always_good 9y ago

I cringe at the thought of using so few features of Postgres that you can actually use Sqlite.

_rami_ 9y ago
Me too, at times. Django makes it bearable though, and going forward we'll probably use more advanced features of PostgreSQL in places where we can fail gracefully or fall back to simpler behaviour on other databases.
- mattmanser 9y ago
  I honestly feel sad for your colleagues, from your comments on this thread it sounds like you've made a very unnecessarily complicated, over-engineered, nightmare of a process they have to suffer through. Everything's got a justification, and the justifications suck. Use postgres, or don't. Having a stupid number of slow tests is the problem to fix, the solution is not limiting your developers to using basic SQL.
  - _rami_ 9y ago
    It certainly is a future perspective for us, moving to all-postgres, but forcing every installation of pretix (an open source application) to go through this migration is not something we'll do overnight ;)
  - foota 9y ago
    Please be civil.

shlomi-noach 9y ago

Agreed, and having some experience with both MySQL and SQLite, running SQLite in testing cannot cover problems you'd find with MySQL (e.g. SQLite is so limited with concurrency that you cannot use it to confirm concurrency issues will be dealt with in your production MySQL). I would assume the same holds for SQLite<->PostgreSQL.

_rami_ 9y ago
Sure, there are often problems differing between the databses. Our Travis CI configuration runs our test suite against all three different databases: https://travis-ci.org/pretix/pretix/builds/351704035 https://travis-ci.org/pretix/pretix/builds/351704035 However, having SQLite at hand for local development/testing makes things easier. In my experience, real-world concurrency issues (that you are talking about) are always hard to find in manual/automated testing, or do you have a good strategy of trying that?
- shlomi-noach 9y ago
  > In my experience, real-world concurrency issues (that you are talking about) are always hard to find in manual/automated testing I agree, and I don't have a good, generic, strategy for that. I didn't give the best example.

ubernostrum 9y ago

Depends. For apps that I distribute generically for use with Django, I usually stick only to ORM features that are supported across all backends. And then I just have tox set up to run the tests with an in-memory SQLite database, since that's fast (and Django's test suite already exercises its ORM on all the backends, so I can trust the ORM will work on other DBs). My personal blog, though? I run Postgres locally on my laptop (via Postgres.app) to make the dev/testing environment as similar as possible. Most places I've worked have done similarly, running either Postgres or MySQL locally, and I have run into bugs that only manifested on MySQL (not because of bugs in Django, but because of MySQL acting in the way MySQL acts).

_rami_ 9y ago

Our development setup currently does not need Docker at all. In fact, it does not need a lot more than git and a recent Python version: https://docs.pretix.eu/en/latest/development/setup.html https://docs.pretix.eu/en/latest/development/setup.html I agree that this is an opinionated setup and I do see the value of a development setup that mirrors production closely. (1) During testing, in-RAM SQLite databases are really fast and well capable of running tests in parallel. We have a test suite of ~2000 tests that currently needs ~4min to run on a modern notebook with four threads, so this matters. (2) pretix is an open source project. If we'd only have a small number of developers in an in-house team, I wouldn't care at all. However, there are many people contributing small and large features and fixes to pretix, and many of them are drive-by contributions: People fixing a problem they just experienced and then leaving again. I want to make it easy for these people, even if they use operating systems where installing Docker first might be a hoop they do not want to jump through. That said, deprecating MySQL at some point would also force all self-hosting users of pretix to go through all the steps we did here, so this wouldn't be viable in the short term.

_rami_ 9y ago
I may add that our development setup has no external service dependencies, redis is optional as well. Of course, we wouldn't recommend that in production, but we're kinda proud that it's possible.
fovc 9y ago
2000 tests in 4 minutes actually sounds really slow. We use postres and our Django tests run at roughly 9000/min on 3 year old laptops. Start your pg container once and use Django's -k flag when running tests to avoid start up times. We also take care to separate DB access from business logic and to unit test those separately.
- _rami_ 9y ago
  Sure, the main reason for this is that nearly all of our tests touch the database and operate on a comparatively high level, we have way more things in a fuzzy category between functional and integration tests than actual unit tests. This is of course a flaw in our test writing, but it's what we have right now ;)

audiolion 9y ago

Agreed, I originally did this and the first time I ran into a prod bug because sqlite and Postgres differ in implementation of some more advanced methods I immediately moved off it and never looked back. A lot of people stick with sqlite in dev because when you start a django project it will default to that. Even if you dont use Docker, brew install postgresql is just as simple. The commands to setup a user are like 3 lines. 20 mins of doc searching and one time README setup.

nh2 9y ago
This doesn't need docker and not even 20 minutes. initdb -D mypostgresdatadir # creates the DB postgres -D mypostgresdatadir -p 1234 # runs DB on given port Done. On systems like Ubuntu, these binaries live in e.g. `/usr/lib/postgresql/9.5/bin/postgres`.