4 ms·

For me it's too much easy to write them with sql or plpgsql.. and later I can use them from node, rust, go.. or whatever.. for me the dB (the model) it's the so

by jordic 6y ago

For me it's too much easy to write them with sql or plpgsql.. and later I can use them from node, rust, go.. or whatever.. for me the dB (the model) it's the source of thruth that will lasts.. independent of the language that interacts with it... Also the problem gets worst if you add to the mix something like elastic search. That it also has it's own schema and it's also has to be migrated..

bb88 6y ago
But now you've got the issue that the code needs to match the DB. Django takes care of this for you. It's really quite nice.
- jordic 6y ago
  That's the trade-off if you decouple the dB from the web framework you have to take care of both.. :) anyway, I prefer to trust the dB (real data on it) that a bunch of complicated things on the Django side.. (I suspect that happened something similar to me when I started reviewing crazy (shoot your food) class based elaborations..
- giancarlostoro 6y ago
  You can always tell Django's ORM not to manage any of your data and write all your queries. You can also tell Django to give you the query it generates, tweak it (if / as necessary) and run from there.
  - bb88 6y ago
    But why? Granted if you have super complex queries, sure. But 95-99% of the queries are simple typically.