5 ms·

I can't say I can recommend following almost any of this as "general" advice. It is, at best, advice from a complete expert for complete experts who are already

by ris 6y ago

I can't say I can recommend following almost any of this as "general" advice. It is, at best, advice from a complete expert for complete experts who are already pushing the edge of what django should be used for, and who never expect to have to hand off their project to an average web developer. I've had to come to terms with the fact that the average web developer is going to screw up e.g. writing their schema by hand in sql. And I know I'll likely be the person inheriting this two generations of developer after the original wizard left. For an average web developer, someone just getting into django, or someone who isn't yet running into the limitations that the author apparently is, this is a recipe to just make a huge mess. It's also very specific advice. Recommending ignoring cross-database concerns.. I'm sure that's fine if you're an end-user developer building and running your own product, but if you're considering writing a library or reusable app you'd like to be useful to other django users, it's probably worth a second thought. It's ironic though that the author makes such a prominent mention of "You Ain't Gonna Need It", because that's exactly what I'd say about most of the pimped-up tweaks mentioned here. 99% of people aren't going to run into these limitations and will produce a much more maintainable app by following the standard django doctrine.

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.
paganel 6y ago
> I've had to come to terms with the fact that the average web developer is going to screw up e.g. writing their schema by hand in sql I've been writing Django apps since the 0.96 days (so, well before they officially implemented "migrate-able" schemas) and I'm still nervous af when having to manually edit/modify a schema file inside of ./migrations. As such, things like > python manage.py makemigrations that work 99% of the time have been a god-sent to me.
allendoerfer 6y ago
I would say the same. It is about team size: If you are alone and don't care whether your client succeeds after you've got fired: Go for it. If you are in a really complex structure, you most likely have dedicated database people, who want to do their thing anyway. In any other circumstance, it is a really bad idea to ignore the standards of your framework and build your own thing. If you have to manually change the database, at least stick it into a standard migration. Don't use your own thing. Documentation will be lacking, edge cases will be ignored, the old standard will still stick around and new people will try to use it.
echlebek 6y ago
I'm skeptical that giving someone that doesn't understand databases a tool to automate their use will result in a better situation long term. A determined programmer can always make a huge mess. I will admit: I'm an ORM disliker, preferring to write all my SQL by hand. SQL is a wonderful language and it's often far easier to do things in SQL than in whatever imperative language you happen to be using. I also enjoy far better performance than most (any?) ORMs can offer, simply by using prepared statements. I have far greater control over batching, should I wish to employ it. When things are going wrong, it's simpler in my experience to audit human-written SQL than it is to audit whatever stuff an ORM decides to emit for a given situation. I agree with ignoring cross-database concerns, as I feel that you will be leaving the finer features of your database on the table if you stick to the basics. Here's the real counterpoint though. If you write SQL, then you can swap out your slow, single-threaded, interpreted programming language for one with a bit more punch. And you can even do it piecemeal. To me, that's a much more compelling hedge than swapping out a DBMS.

by ris 6y ago

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.

paganel 6y ago

> I've had to come to terms with the fact that the average web developer is going to screw up e.g. writing their schema by hand in sql I've been writing Django apps since the 0.96 days (so, well before they officially implemented "migrate-able" schemas) and I'm still nervous af when having to manually edit/modify a schema file inside of ./migrations. As such, things like > python manage.py makemigrations that work 99% of the time have been a god-sent to me.

allendoerfer 6y ago

I would say the same. It is about team size: If you are alone and don't care whether your client succeeds after you've got fired: Go for it. If you are in a really complex structure, you most likely have dedicated database people, who want to do their thing anyway. In any other circumstance, it is a really bad idea to ignore the standards of your framework and build your own thing. If you have to manually change the database, at least stick it into a standard migration. Don't use your own thing. Documentation will be lacking, edge cases will be ignored, the old standard will still stick around and new people will try to use it.

echlebek 6y ago

I'm skeptical that giving someone that doesn't understand databases a tool to automate their use will result in a better situation long term. A determined programmer can always make a huge mess. I will admit: I'm an ORM disliker, preferring to write all my SQL by hand. SQL is a wonderful language and it's often far easier to do things in SQL than in whatever imperative language you happen to be using. I also enjoy far better performance than most (any?) ORMs can offer, simply by using prepared statements. I have far greater control over batching, should I wish to employ it. When things are going wrong, it's simpler in my experience to audit human-written SQL than it is to audit whatever stuff an ORM decides to emit for a given situation. I agree with ignoring cross-database concerns, as I feel that you will be leaving the finer features of your database on the table if you stick to the basics. Here's the real counterpoint though. If you write SQL, then you can swap out your slow, single-threaded, interpreted programming language for one with a bit more punch. And you can even do it piecemeal. To me, that's a much more compelling hedge than swapping out a DBMS.