I’m very much an Odoo guy who has dabbled with Django (and notably, celery in the past) but as someone who makes huge use of the Odoo OCA queue module[0], I never understood why Django never made use of the Postgres LISTEN/NOTIFY to offload tasks. Maybe this is my misunderstanding as I’m pretty green with the Django ecosystem as a whole.
Django: what’s new in 6.0
101–110 of 127 posts
Re: Django: what’s new in 6.0
#102I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasi…
Do you use Django's multiple databases support ? (https://docs.djangoproject.com/en/6.0/topics/db/multi-db/)
Re: Django: what’s new in 6.0
#103I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasi…
Also don't underestimate setting up e.g. views or materialized views even that you can use through the ORM to query. It helps a lot and allows you to combine fine tuning SQL with ease of use through Django, and get a lot of performance out of it. Just remember to create them in the migration scripts.
Re: Django: what’s new in 6.0
#104Earlier quoted context omitted.
Exactly. There are a few libraries to achieve a similar thing in Python: * https://htpy.dev/ * https://pypi.org/project/fast_html/ * https://fastht.ml/ (different to above, I think) * https://github.com/volfpeter/fasthx Probably others. I strongly prefer this to templating, but I find it makes dyed in the wool Django people squirm.
I like this approach. I am especially drawn to the idea of making custom components this way but every time I have experimented with this I get burned by the context which has to be passed down through all functions. A jinja/django template has an implicit context but for nested functions you really have to pass that context down through every function call. It inevitably ends up just a big dict blob. You get some ty…
htpy supports passing data between multiple levels components with its context (very similar to React):
Re: Django: what’s new in 6.0
#105I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasi…
Maybe this shows my data analyst tendencies, but why not use SQL?
That’s what we do now. But it gets repetitive and not leveraging Django core features.
Re: Django: what’s new in 6.0
#106I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasi…
I've been using Django for the last 10+ years, its ORM is good-ish. At some point there was a trend to use sqlalchemy instead but it was not worth the effort. The Manager interface is also quite confusing at first. What I find really great is the migration tool.
Re: Django: what’s new in 6.0
#107I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasi…
I've used Aldjemy (https://github.com/aldjemy/aldjemy) on a small project and it worked pretty well for allowing me to compose the fairly complex queries needed that the Django ORM couldn't do.
Re: Django: what’s new in 6.0
#108Earlier quoted context omitted.
Why is celery awful?
Because it’s a seducer. It does what you need to do and you two are happy together. So you shower more tasks on Celery and it becomes cold and non-responsive at random times. And debugging is a pain in the ass. Most places I’ve been that have it, I’ve tried to sell them on adding Flower to give better insight and everyone thinks that’s a very good idea but there isn’t time because we need to debug these inscrutable C…
Although we could say the same thing about Kafka, couldn't we? It's made for much higher throughput and has usually other use cases, but it's also great until it's not great.
Re: Django: what’s new in 6.0
#109Re: Django: what’s new in 6.0
#110I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasi…
Agreed, and their DB migration workflow leaves much to be desired. By not storing a schema/DB state alongside code, Django depends on the current DB state to try and figure it out from scratch every time you run a DB command. Not to mention defining DB state from model code is inherently flawed, since models are abstractions on top of database tables. I much prefer the Rails way of composing migrations as specific DB instructions, and then getting models 'for free' on top of those tables.