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

131–140 of 209 posts

Re: Django 3.1

#131

Post by pyrophane »

rs999gti wrote: post #114
kumarvvr wrote: post #13

OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?

Does the backend language of a CMS matter? We are a .NET shop, we'd love to use Django, Drupal, etc. But does that also mean we need a dedicated Python resource to support these CMS'? Or could we use these CMS' out of the box? Or would we just be better off with a .NET CMS like Umbraco or Orchid?

If you use a CMS to build something of any complexity, you will almost inevitably wind up writing some custom code for it. In that case, I think the most important thing, much more important than what language the developers chose, is how extensible and well-documented it actually is.

Re: Django 3.1

#132

Post by mrweasel »

kumarvvr wrote: post #13

OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?

We actually had to make that choice 10 years ago. .NET was out because we didn’t want to deal with Windows server, but that’s no longer an issue. Now I think I would skip ASP.NET because everything is confusing as all hell. You don’t know which .NET supports which feature, or even what you’re suppose to be running. It’s the fastest of the three and Visual Studio is still an awesome IDE.

We dropped PHP due to the lack of any really good frameworks, but now we have Laravel. PHP is still a solid choice and it’s fast.

In the end we went with Django because we liked Python and Django is really well documented and easy to learn.

Re: Django 3.1

#133

Post by sandGorgon »

grenoire wrote: post #6

JSONField 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.

Looks like similar to Pydantic (included by default in Fastapi)

Re: Django 3.1

#135

Post by kfarr »

agumonkey wrote: post #106
oliwarner wrote: post #105

Earlier quoted context omitted.

We've been using it pretty heavily and the ability to do deep queries like Person.objects.filter(data__family__spouse__name__istartswith="oli") is great for one-offs but the performance stinks . As it well should —this isn't a complaint— just a reminder that keeping denormalised, first party data that can be well indexed is invaluable when you're talking about huge datasets. It'd also be nice to layer in JSON Schema…

> data__family__spouse__name__istartswith="oli" that's some syntax right there :)

Couldn't tell if you meant to say it was good or bad, but actually I found it to be crystal clear which is impressive for a complicated dataset.

Re: Django 3.1

#136

Post by enraged_camel »

metafunctor wrote: post #27
grenoire wrote: post #6

JSONField 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…

>>In projects I've been involved with, storing JSON in the database has often turned out to be a mistake.

I mostly agree. The only JSON I store in the database is UI settings, because it's easy enough to parse it with JavaScript (and fall back in default if the JSON doesn't contain that prop). It also decouples your database schema from the UI, the latter of which can evolve much more rapidly.

For everything else, having a schema is better.

Re: Django 3.1

#137

Post by theptip »

Alex3917 wrote: post #53
metafunctor wrote: post #27

Earlier 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…

> If you find yourself implementing your own validation and schema code for JSON fields, I'd say it's a sign that you should probably stop and migrate the data to Django models instead. Don't agree. Where JSON fields with validators are useful is when you would otherwise have inherited models for different variants of the same type of thing. It's a lot easier to understand and query one model with 50 Cerberus (or wha…

I am skeptical (with an open mind) of the JSONField pattern. We’ve used it in a few places where you have something like inheritance, so you want to handle all Event objects the same at the top level, and then dispatch differently based on Type. This works fine.

My concern is that this is a pattern which experts advocate, but less precise/experienced engineers are likely to break when it comes time for a data migration.

With normal SQL fields, if you change the schema you need to create a migration, and that gives an easy point to check for datamigrations too. If any commit can silently change the write-schema, it’s a lot harder to police.

So I suspect if your team skews towards very experienced engineers the JSONField pattern probably gains in value. If that’s right it’s probably best to caveat the recommendation.

Interested to know your experiences with schema changes though.

I’m also interested to note that you are pointing out a general issue with Django I’ve experienced - the Models spread through the whole system. You can solve that in other ways, say by having a repository layer that used normal (non-JSONField) models and maps them through to a POPO. I’m not sure you _need_ the JSONField pattern to get the separation you’re looking for.

Re: Django 3.1

#138

Post by theptip »

formerly_proven wrote: post #120
OJFord wrote: post #36

Earlier quoted context omitted.

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').

> Access, but not constrain or type-check. You can create CHECK constraints involving JSON operations in postgres, which is the same way you'd enforce any constraint.

Manually, right? Django autogenerates all of the SQL schema for you on non-JSON fields. You could replicate that work, but that sounds tedious.

Re: Django 3.1

#139

Post by theptip »

brylie wrote: post #82
heliodor wrote: post #73

Earlier quoted context omitted.

Can you please elaborate on the "wealth of tooling" part? Makes me wonder what I don't know...

Some useful ORM extensions that I know of include: - Core Forms and Class-based views - https://django-extensions.readthedocs.io/en/latest/model_ext... - https://django-model-utils.readthedocs.io/en/latest/ - https://django-queryable-properties.readthedocs.io/en/stable... - https://django-mptt.readthedocs.io/en/latest/ - https://rsinger86.github.io/django-lifecycle/

Also the ModelAdmin won’t be friendly for JSON data.

Re: Django 3.1

#140

Post by Alex3917 »

theptip wrote: post #137
Alex3917 wrote: post #53

Earlier quoted context omitted.

> If you find yourself implementing your own validation and schema code for JSON fields, I'd say it's a sign that you should probably stop and migrate the data to Django models instead. Don't agree. Where JSON fields with validators are useful is when you would otherwise have inherited models for different variants of the same type of thing. It's a lot easier to understand and query one model with 50 Cerberus (or wha…

I am skeptical (with an open mind) of the JSONField pattern. We’ve used it in a few places where you have something like inheritance, so you want to handle all Event objects the same at the top level, and then dispatch differently based on Type. This works fine. My concern is that this is a pattern which experts advocate, but less precise/experienced engineers are likely to break when it comes time for a data migrati…

> If any commit can silently change the write-schema, it’s a lot harder to police.

In addition to schema validators, you really also need a data integrity async task that runs once a day to catch these kinds of issues. They're not that hard to fix if you catch them early, it's if you realize there's a data integrity issue years later and the original team isn't even there anymore that you get bigger problems. If you have a lot of data, a reasonable solution is just having it run on everything from the last 24 hours plus a random sampling of data older than that.

> Interested to know your experiences with schema changes though.

Haven't done a ton, so admittedly there could be complex cases I'm not seeing. I think it helps though, in cases like the example I gave of using it for form-like things, to set it up like:

  QuizModel
  QuizQuestionModel (FK to QuizModel)

  QuizResponseModel (FKs to QuizModel, UserModel)
  QuizQuestionAnswerModel (FKs to QuizResponseModel, QuizQuestionModel)
This way you have four models rather than an indefinite number. But because it's not just one big model with lists of JSON objects for questions and responses, this makes running migrations and data integrity checks much simpler to write and easier to reason about.

The idea being also that you have JSON schema validators for the different types of JSON blobs that get stored in QuizQuestionModel and QuizQuestionAnswerModel.

Post reply on HN