Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 3.1

djangoproject.com

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Django 3.1

#201

Post by Daishiman »

jtdev wrote: post #181
Daishiman wrote: post #178

Earlier quoted context omitted.

Nobody who builds an ORM thinks that. An ORM saves experienced SQL users from having to write boilerplate SQL and hack on their own garbage ORM, which is what any large project ends up doing, attempting to compose queries and filters in vain. I have never ever heard of ORMs as an argument to avoid learning SQL, and AFAIK no author of well-known ORMs holds that opinion.

"boilerplate SQL" is an oxymoron... Literally every pro-ORM dev that I've ever worked with was so incredibly weak with basic SQL fundamentals that I must conclude that they preferred ORMs simply due to a reluctance to learn SQL.

Your industry experience is minimal then.

Re: Django 3.1

#202

Post by btown »

georgewalker355 wrote: post #191
mgraczyk wrote: post #166

Earlier quoted context omitted.

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.

> DB ORM operations just work with gevent My impression was that django+gevent requires some care for the db part. The psycopg2 docs state, for instance "Psycopg connections are not green thread safe and can’t be used concurrently by different green threads." [1,2]. In addition, gevent cannot monkey patch psycopg2 code because it is C and not python. This is handled by calling psycopg2.extensions.set_wait_callback()…

In practice this is just a one-time setup. We use https://github.com/jneight/django-db-geventpool which uses psycogreen under the hood. It isn't perfect (we're currently tracking down some rare cases where connections aren't properly returning to the pool, though we believe this to be error on our side) but it's more than sufficient.

While making the ORM async capable would be great, I'm not sure it will ever make sense to migrate towards sprinkling "async" explicitly across our codebase. We'll see, of course.

Re: Django 3.1

#203

Post by heliodor »

bredren wrote: post #199
heliodor wrote: post #192

Earlier quoted context omitted.

No. Celery can execute tasks after your view returns. Async can't do that.

Would you please elaborate? If all of a task is encapsulated in a django async view, would this not be the same thing?

To run async code, you use 'await' in python. That right there tells you that you have to wait for it to finish. You want to receive the result. The view will wait for a result before returning the http response.

Celery and all task queues are fire-and-forget. You tell it to do something for which you don't want the result, so you can continue executing your code right away. The task queue can even take an hour to process, for example. Or you can schedule it to run later.

Re: Django 3.1

#204

Post by samirsd »

heliodor wrote: post #203
bredren wrote: post #199

Earlier quoted context omitted.

Would you please elaborate? If all of a task is encapsulated in a django async view, would this not be the same thing?

To run async code, you use 'await' in python. That right there tells you that you have to wait for it to finish. You want to receive the result. The view will wait for a result before returning the http response. Celery and all task queues are fire-and-forget. You tell it to do something for which you don't want the result, so you can continue executing your code right away. The task queue can even take an hour to pr…

thanks

Re: Django 3.1

#205

Post by alanfranz »

StavrosK wrote: post #45
alanfranz wrote: post #40

Earlier quoted context omitted.

Typical use case: There are a number of required fields that your app won't work without. Those should be columns, probably non-nullable columns. Then there're a bunch of optional fields. Traditionally, a number of nullable cols would be created. But they're ultimately messy (need to null check every accesses) and unneeded since you can replace them with a single json item. Keys are always optional, so you always nee…

Fields are messy because you have to check for nulls, yet JSON keys aren't messy because you have to check for nulls?

All json keys are optional, so you ALWAYS need to check for their presence or absence. Mess exists when some key is nullable and some isn't. Checking for nullability on a key that can never be null isn't extremely elegant.

Re: Django 3.1

#206

Post by StavrosK »

alanfranz wrote: post #205
StavrosK wrote: post #45

Earlier quoted context omitted.

Fields are messy because you have to check for nulls, yet JSON keys aren't messy because you have to check for nulls?

All json keys are optional, so you ALWAYS need to check for their presence or absence. Mess exists when some key is nullable and some isn't. Checking for nullability on a key that can never be null isn't extremely elegant.

Why is that a mess? I don't see the difference.

Re: Django 3.1

#209

Post by jklein11 »

fastball wrote: post #208
jklein11 wrote: post #207

Earlier quoted context omitted.

Why not store this data into a relational database?

Because values can be different types (string, int, boolean).

Can't you store them all as varchar? You could even have a type column if you wanted to enforce the types in some way at the application level.
Post reply on HN