Live data from Hacker News

Django 3.1

djangoproject.com

161–170 of 209 posts

Re: Django 3.1

#161
post #151

Earlier quoted context omitted.

Django ORM mainly hides the SQL from the developer (which is kind of the idea of any ORM). But if a developer does not understand the underlying SQL concepts, they will soon write performance wise horrific code. But, if you remove the ORM from that equation, I don't see how that same developer doesn't make the same mistakes. So in the end, I don't think that Django ORM (in its core) can help much in this area. There…

This is a hot-take from Aaron Patterson, Rails and Ruby core team dev, in his keynote this year where he addressed a very similar idea on a perhaps related query generation topic... https://youtu.be/9JEEabL90AA?t=1360 To give you the tl;dr (he goes through profiling and a great deal of data to help show what a core dev needs to do in order to help us solve this one specific case, and...) Aaron comes to the conclusion…

While a good point, I would say the problem is caused by ORMs existing. Somehow somewhere we decided that a person who thinks SQL is too difficult should be using a database.

Re: Django 3.1

#162
Something I wish that Django did was user defined functions in the template. It has for loops, which is good but it forces you to write the html in top to bottom procedural manner.

It would be far better to be able to define a function that you can call for bits of html code that might repeat in the same template.

Since I stopped using Django at 1.6 does the new version let you define functions in the templates?

Re: Django 3.1

#163

Something I wish that Django did was user defined functions in the template. It has for loops, which is good but it forces you to write the html in top to bottom procedural manner. It would be far better to be able to define a function that you can call for bits of html code that might repeat in the same template. Since I stopped using Django at 1.6 does the new version let you define functions in the templates?

It has blocks for this https://docs.djangoproject.com/en/3.0/ref/templates/builtins...

Re: Django 3.1

#164

Something I wish that Django did was user defined functions in the template. It has for loops, which is good but it forces you to write the html in top to bottom procedural manner. It would be far better to be able to define a function that you can call for bits of html code that might repeat in the same template. Since I stopped using Django at 1.6 does the new version let you define functions in the templates?

Django has full Jinja support these days which is vastly preferable.

Re: Django 3.1

#165

As someone that has an active app still written in Django 1.6. The larger my project and more complicate the more I wanted to ditch the model/view/template separation. And attach methods to the model so that it can be called from everywhere, returning html code in a string directly. Other times, I wished Django had something analogous to a component, where everything is just encapsulated in a single file. I don't wan…

> I don't want to separate javascript/html/css view/template. I want a single file

This was always possible.

Re: Django 3.1

#166
post #147

I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time. Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a…

As an FYI: Using a gevent monkey patch has been a way to get async Django for years. Overhead is inefficient in CPU cycles and you need to stay away from doing CPU bound things like Numpy manipulations, but for an app server that’s bound by external API call latency, it practically gives infinite concurrency compared to a thread-per-request model. And no need to worry about event queues. You can feel free to synchron…

I'd add that crucially, DB ORM operations just work with gevent. It will be a while before async database operations are supported natively by Django. For me that is a complete blocker.

Re: Django 3.1

#167

Something I wish that Django did was user defined functions in the template. It has for loops, which is good but it forces you to write the html in top to bottom procedural manner. It would be far better to be able to define a function that you can call for bits of html code that might repeat in the same template. Since I stopped using Django at 1.6 does the new version let you define functions in the templates?

It has blocks for this https://docs.djangoproject.com/en/3.0/ref/templates/builtins...

That isn't as nice to having a function inside the same file you can call over, IMHO.

Also lets say you define a block for rendering a button with a different color. Then use 20 different buttons on one page.

Does that mean that the block code would need to be loaded from a file 20 times and parsed each time. Seems like huge performance hit to do it that way.

Is there a technical reason why you can't have a function in the same file.

Am I misunderstanding how it works?

Re: Django 3.1

#168

Something I wish that Django did was user defined functions in the template. It has for loops, which is good but it forces you to write the html in top to bottom procedural manner. It would be far better to be able to define a function that you can call for bits of html code that might repeat in the same template. Since I stopped using Django at 1.6 does the new version let you define functions in the templates?

Django has full Jinja support these days which is vastly preferable.

Can you write functions in Jinja?

Re: Django 3.1

#170
post #151

Earlier quoted context omitted.

Django ORM mainly hides the SQL from the developer (which is kind of the idea of any ORM). But if a developer does not understand the underlying SQL concepts, they will soon write performance wise horrific code. But, if you remove the ORM from that equation, I don't see how that same developer doesn't make the same mistakes. So in the end, I don't think that Django ORM (in its core) can help much in this area. There…

This is a hot-take from Aaron Patterson, Rails and Ruby core team dev, in his keynote this year where he addressed a very similar idea on a perhaps related query generation topic... https://youtu.be/9JEEabL90AA?t=1360 To give you the tl;dr (he goes through profiling and a great deal of data to help show what a core dev needs to do in order to help us solve this one specific case, and...) Aaron comes to the conclusion…

I would be very hesitant to turn an ORM into a "smart" SQL generator. Depending on the type/distribution of data, there are sometimes very different paths to optimizing a query. The ORM as a "stupid" SQL generator (straightforward mapper) is a great way to allow for the flexibility to control how a query is generated.

The DB engine might be the place for those sort of improvements.

Post reply on HN