4 ms·

I don't have experience with Django model migrations so can't comment on that - but running script based migrations without a CI like that in any nontrivial env

I don't have experience with Django model migrations so can't comment on that - but running script based migrations without a CI like that in any nontrivial environment sounds like asking for trouble, but how did you not catch the issue when a dev pulls from master and migrations aren't working - everyone just does local patching and ignores that the master is broken ? I've seen this on a .NET project, we didn't have a CI and this one guy had a tendency to commit dirty migration scripts breaking people's databases - I've seen it slip a few times to the QA deploy process before it gets caught because everyone assumed he would fix his shit and was too busy cleaning up his crap so we would just comment it out locally to get it to run.

bb88 6y ago
Django migration scripts are run by devs after pulling from Master as well as deploying to prod. That gives everyone the same confidence that the migrations are working. If the migrations are borked, they get fixed or the prod deployment will break. Ideally this should be part of the CI/CD process for the PR. Also it's worth noting that you can run all migrations from the beginning of time to the latest version on a development DB. And I believe the default Django unit testing framework does this by default.
jordic 6y ago
The problem sounds like merging things that are not green on CI, not related to migrations with python Vs sql). Think on it, you can just use Django on python, but you can use sql everywhere there is a dB.
- bb88 6y ago
  > Think on it We did. And with smart people who knew SQL inside and out. It just made sense to not hand roll SQL anymore, because Django caught most of the errors we had.
  - jordic 6y ago
    Learn sql, it's like javascript, it's everywhere.. and will open you expertise from a we framework to a lot of other places..
    - bb88 6y ago
      You make it sound I don't know SQL. That's kind of insulting, you know?
    - jordic 6y ago
      Mmm, sorry, if this is how you see it, what I'm trying to express it's that the dB by itself, it's the source of truth (and the state) of your application, Django it's just an implementation detail that you can swap whenever you need.
      - bb88 6y ago
        Think about a cognizant response rather than assuming ignorance, which seems to be a common theme with HN posters.
      - theamk 6y ago
        Sometimes yes. And sometimes you have many other things to do and you want your database to just work. In this case it is perfectly fine to rely on ORM. It is like C vs Python: yes, I know C pretty well. Yes, it is significantly faster. I am still going to write the project in Python.
    - mistrial9 6y ago
      I think the posters are talking about cooking, make sweeter, no make it more like bread.. etc.. The design objective and architectual considerations could make either of these two "right" .. however, some weight given to a repeated mention of "average web developer" .. if that is the ONLY topic, then some clarification could be skipped... (yes, learn SQL)

bb88 6y ago

Django migration scripts are run by devs after pulling from Master as well as deploying to prod. That gives everyone the same confidence that the migrations are working. If the migrations are borked, they get fixed or the prod deployment will break. Ideally this should be part of the CI/CD process for the PR. Also it's worth noting that you can run all migrations from the beginning of time to the latest version on a development DB. And I believe the default Django unit testing framework does this by default.

jordic 6y ago

The problem sounds like merging things that are not green on CI, not related to migrations with python Vs sql). Think on it, you can just use Django on python, but you can use sql everywhere there is a dB.

bb88 6y ago
> Think on it We did. And with smart people who knew SQL inside and out. It just made sense to not hand roll SQL anymore, because Django caught most of the errors we had.
- jordic 6y ago
  Learn sql, it's like javascript, it's everywhere.. and will open you expertise from a we framework to a lot of other places..
  - bb88 6y ago
    You make it sound I don't know SQL. That's kind of insulting, you know?
  - jordic 6y ago
    Mmm, sorry, if this is how you see it, what I'm trying to express it's that the dB by itself, it's the source of truth (and the state) of your application, Django it's just an implementation detail that you can swap whenever you need.
    - bb88 6y ago
      Think about a cognizant response rather than assuming ignorance, which seems to be a common theme with HN posters.
    - theamk 6y ago
      Sometimes yes. And sometimes you have many other things to do and you want your database to just work. In this case it is perfectly fine to rely on ORM. It is like C vs Python: yes, I know C pretty well. Yes, it is significantly faster. I am still going to write the project in Python.
  - mistrial9 6y ago
    I think the posters are talking about cooking, make sweeter, no make it more like bread.. etc.. The design objective and architectual considerations could make either of these two "right" .. however, some weight given to a repeated mention of "average web developer" .. if that is the ONLY topic, then some clarification could be skipped... (yes, learn SQL)