3 ms·

For my company I wrote internal django apps that are completely database agnostic. They can be run in testing with sqlite, postgres, oracle, etc.

by bb88 6y ago

ddorian43 6y ago
I don't ever agree with this. You end up using only the (minimal) features that they all support. I can't imagine going from PostgreSQL features to MySQL. And you should always dev/test/stage on the same database that you'll use in production.
- bb88 6y ago
  Everything you're saying is true, but if the devs can run unit tests on sqlite, that's a big win. And you shouldn't discount this feature off hand, or limit yourself from being able to do this. It's one thing if you want to run postgres locally, that's fine, but who really wants to run Oracle on their laptop just to run unit tests, or to test an api locally?
djrobstep 6y ago
This seems to have minimal upside and heaps of downside - you can only use the features that every database has. You should be running the same database in test as in production anyway - there are heaps of problems you won't catch if you don't.
- JonAtkinson 6y ago
  The majority of apps need a very small subset of database features; they need somewhere to park strings and numbers in a reliable way, and retrieve them (sometimes in order). The Django ORM supports this across all of the backends it supports.
  - djrobstep 6y ago
    Strong disagree - even the basic features and data types of databases have subtle but critical differences. You should be free to use the features available, not waste your time optimising for databases that don't have those features but that you will likely never switch to anyway.
    - bb88 6y ago
      95-99% of your app is data and query optimization. And django seems to do all of this just fine really.
berkes 6y ago
That severely limits you though. And I'm not talking about postgis, hstore or such exotic features. I'm talking about indexes, transactions, locking and other basic feature that is often missing or implemented very different across databases. You may not need, say, GIST indices that help when sorting "tweets by recent activity" for your proof of concept or even your test-env but you certainly do for production, or else you are truly missing out. And such basic tools are avaialble in most database-engines, but differ very much in how exactly they are implemented, to be used and to be tuned.
- bb88 6y ago
  Django supports indexes, transactions, and locking, and if I need to specify raw SQL I can do that during a migration say. 90% of what I need is already there. And if I need something special, I can add it in later.
  - berkes 6y ago
    I'm not familiar enough with Django, but assume it being very similar to Rails (Ruby). The migrations and ORM allows for a lot of indexing, but lacks the last 20%, which -logically- is DB specific indexing. But also the indexing that gets the majority of the improvements. Locking is another thing: lowest commnon denomimator is bad. But works, for sqlite, mysql and postgres (and probably oracle, never tried). Yet is so naive that it does more harm that good. In Rails they've worked on this and moved far beyond the lowest-common-denominator with Adapters and other patterns. That adds such an amount of indirections that it does more harm than good, when debugging where that weird "why did it choose to use a GIST and not a partial BTREE here". (edit: kept story in line with one usecase. sorry)
    - bb88 6y ago
      TBH, I can't tell if you're complaining about Ruby or Django here. They're two very different things with different methodologies. You can't complain about how Ruby does it's database in a discussion about Django. Like I said elsewhere, Django offers a lot, and what it doesn't offer can always be added with raw SQL.

For my company I wrote internal django apps that are completely database agnostic. They can be run in testing with sqlite, postgres, oracle, etc.

by bb88 6y ago

For my company I wrote internal django apps that are completely database agnostic. They can be run in testing with sqlite, postgres, oracle, etc.

ddorian43 6y ago

I don't ever agree with this. You end up using only the (minimal) features that they all support. I can't imagine going from PostgreSQL features to MySQL. And you should always dev/test/stage on the same database that you'll use in production.

bb88 6y ago
Everything you're saying is true, but if the devs can run unit tests on sqlite, that's a big win. And you shouldn't discount this feature off hand, or limit yourself from being able to do this. It's one thing if you want to run postgres locally, that's fine, but who really wants to run Oracle on their laptop just to run unit tests, or to test an api locally?

djrobstep 6y ago

This seems to have minimal upside and heaps of downside - you can only use the features that every database has. You should be running the same database in test as in production anyway - there are heaps of problems you won't catch if you don't.

JonAtkinson 6y ago
The majority of apps need a very small subset of database features; they need somewhere to park strings and numbers in a reliable way, and retrieve them (sometimes in order). The Django ORM supports this across all of the backends it supports.
- djrobstep 6y ago
  Strong disagree - even the basic features and data types of databases have subtle but critical differences. You should be free to use the features available, not waste your time optimising for databases that don't have those features but that you will likely never switch to anyway.
  - bb88 6y ago
    95-99% of your app is data and query optimization. And django seems to do all of this just fine really.

berkes 6y ago

That severely limits you though. And I'm not talking about postgis, hstore or such exotic features. I'm talking about indexes, transactions, locking and other basic feature that is often missing or implemented very different across databases. You may not need, say, GIST indices that help when sorting "tweets by recent activity" for your proof of concept or even your test-env but you certainly do for production, or else you are truly missing out. And such basic tools are avaialble in most database-engines, but differ very much in how exactly they are implemented, to be used and to be tuned.

bb88 6y ago
Django supports indexes, transactions, and locking, and if I need to specify raw SQL I can do that during a migration say. 90% of what I need is already there. And if I need something special, I can add it in later.
- berkes 6y ago
  I'm not familiar enough with Django, but assume it being very similar to Rails (Ruby). The migrations and ORM allows for a lot of indexing, but lacks the last 20%, which -logically- is DB specific indexing. But also the indexing that gets the majority of the improvements. Locking is another thing: lowest commnon denomimator is bad. But works, for sqlite, mysql and postgres (and probably oracle, never tried). Yet is so naive that it does more harm that good. In Rails they've worked on this and moved far beyond the lowest-common-denominator with Adapters and other patterns. That adds such an amount of indirections that it does more harm than good, when debugging where that weird "why did it choose to use a GIST and not a partial BTREE here". (edit: kept story in line with one usecase. sorry)
  - bb88 6y ago
    TBH, I can't tell if you're complaining about Ruby or Django here. They're two very different things with different methodologies. You can't complain about how Ruby does it's database in a discussion about Django. Like I said elsewhere, Django offers a lot, and what it doesn't offer can always be added with raw SQL.