I'm closer to a hobbyist than a professional dev, but the async views seem like a big functionality. Having done some Django apps, getting a synced up view for some changing variable was always a bit painful.
Django 3.1
31–40 of 209 posts
Re: Django 3.1
#32I'm closer to a hobbyist than a professional dev, but the async views seem like a big functionality. Having done some Django apps, getting a synced up view for some changing variable was always a bit painful.
I'm not sure you're talking about the same thing, this is about asyncio/green threads.
Re: Django 3.1
#33JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.
In projects I've been involved with, storing JSON in the database has often turned out to be a mistake. Django models create a well-defined self-documenting structure for your schema, are easy to evolve using migrations, and there's a wealth of tooling built on top. IMHO, these far outweigh the perceived convenience of simply storing some stuff in a JSON field. If you find yourself implementing your own validation an…
100% agreed, JSON fields are good when you want to dump a bunch of data you don't care about the shape of, but if you need a schema, pull the data into actual fields.
Re: Django 3.1
#34I'm closer to a hobbyist than a professional dev, but the async views seem like a big functionality. Having done some Django apps, getting a synced up view for some changing variable was always a bit painful.
I'm not sure you're talking about the same thing, this is about asyncio/green threads.
re-read the documentation but I'm not following. This example:
async def current_datetime(request):
now = datetime.datetime.now()
html = 'It is now %s.' % now
return HttpResponse(html)
Re: Django 3.1
#35Earlier quoted context omitted.
In projects I've been involved with, storing JSON in the database has often turned out to be a mistake. Django models create a well-defined self-documenting structure for your schema, are easy to evolve using migrations, and there's a wealth of tooling built on top. IMHO, these far outweigh the perceived convenience of simply storing some stuff in a JSON field. If you find yourself implementing your own validation an…
100% agreed, JSON fields are good when you want to dump a bunch of data you don't care about the shape of, but if you need a schema, pull the data into actual fields.
For a database like postgres, or even for something like SQLite, this mostly becomes a distinction without a whole lot of difference, since the database can index and access JSON structures just like regular columns.
Re: Django 3.1
#36Earlier quoted context omitted.
100% agreed, JSON fields are good when you want to dump a bunch of data you don't care about the shape of, but if you need a schema, pull the data into actual fields.
For a database like postgres, or even for something like SQLite, this mostly becomes a distinction without a whole lot of difference, since the database can index and access JSON structures just like regular columns.
Access, but not constrain or type-check.
And it's just harder to use, I'm with it being generally a 'mistake' (in the 'you will regret this later' sense) - it's better than text, but I'm in the camp of as much structure as possible ('you will thank yourself later').
Re: Django 3.1
#37OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?
[deleted]
Re: Django 3.1
#38Earlier quoted context omitted.
100% agreed, JSON fields are good when you want to dump a bunch of data you don't care about the shape of, but if you need a schema, pull the data into actual fields.
For a database like postgres, or even for something like SQLite, this mostly becomes a distinction without a whole lot of difference, since the database can index and access JSON structures just like regular columns.
JSONB columns are incredibly useful if you have data that doesn't fit well into a strict relational schema. And they are very powerful in terms of query ability in Postgres, but still quite far from a conventional relational schema.
Queries that act on the insides of a JSONB column are much harder to write than the equivalent conventional queries. They are also much, much slower in certain cases as the DB has to read the entire JSONB blob in many cases, and because they don't have proper statistics. The performance can range from slightly slower to completely pathological query plans that take ages.
I'm a big fan of JSONB in Postgres, but it is no replacement for a relational schema, there are far too many problems you inflict on yourself if you try to use it like that.
Re: Django 3.1
#39Earlier quoted context omitted.
100% agreed, JSON fields are good when you want to dump a bunch of data you don't care about the shape of, but if you need a schema, pull the data into actual fields.
For a database like postgres, or even for something like SQLite, this mostly becomes a distinction without a whole lot of difference, since the database can index and access JSON structures just like regular columns.
As others have mentioned, it definitely does have downsides when it comes to writing queries and especially when using frameworks/libraries to interface with the db.
But for the right job, JSONB columns are awesome!
Re: Django 3.1
#40JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.
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 need to check for presence or absence, and modern dbs support json natively in many clauses.