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

111–120 of 209 posts

Re: Django 3.1

#111

Post by SahAssar »

collyw wrote: post #104
SahAssar wrote: post #95

Earlier quoted context omitted.

Any time you'd otherwise use EAV.

EAV is considered an antipattern. While wouldn't rule out using it, it probably means it should be avoided if there is another solution.

I've been working on a project using schema.org objects (100's of types of objects) in postgres in a graph/tree like structure. While structured the objects are not consistent enough for me to want separate schemas for them. Using JSONb in postgres allows me to index separate fields within the JSON while still having all the objects in a single graph.

If I couldn't use JSONb with indexes (and triggers for custom foreign key checks) it'd be much harder to do this in in a relational database (and the data is relational, it just isn't consistent across all types).

Perhaps this would be better in a Triplestore but there are a lot of features of postgres that are not available in them.

Re: Django 3.1

#112

Post by true_religion »

leetrout wrote: post #96
jsmeaton wrote: post #93

Earlier quoted context omitted.

Adding new SQL support to the Django ORM is tricky. There isn’t a nice low level abstraction for generating and composing SQL. It’s mostly a bunch of lists containing different kinds of data (strings, Col, Expression) and they don’t compose well. On top of that, you’d need to come up with a decent frontend syntax that aligned with the existing methods. I think Django made a mistake when first defining the language of…

Yea I started to bring up the existing ticket for grouping on the dev list and ask what people thought about it. I also ended up writing a very tiny transformer function and using that directly because core only has a couple supported casts and I needed Postgres timestamp types so I could extract and rollup on the year / month / day. That gave me some insight in to some of the patterns in use in “lower level” Django…

SQLAlchemy has a great architecture, but it comes at the expense of being tied to the use case of accessing a relational database.

Django models are more abstract and anemic in querying, but it means you can use the same API and write access layers for non SQL databases. At work, we have an in memory database, and Elastic Search all queried in an identical way to the Postgres models.

Re: Django 3.1

#113

Post by Townley »

DasIch wrote: post #110
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…

Postgres allows you to create an index on keys within a JSONB column[0]. It may be the case that Django doesn't offer support for this but I would expect you can probably get around that with raw SQL. [0]: https://www.postgresql.org/docs/current/datatype-json.html#J...

In addition to raw SQL, postgres JSON fields can be indexed with GinIndex https://docs.djangoproject.com/en/3.0/ref/contrib/postgres/i...

Re: Django 3.1

#114

Post by rs999gti »

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?

Re: Django 3.1

#115

Post by collyw »

stefano wrote: post #92
jtdev wrote: post #79

Does the ORM still write horrendous cursor based loops where simple joins would suffice?

By default yes, but you can configure queries fetching behavior using select_related/prefetch_related to avoid the N+1 queries problem.

Sadly not so many people know how to use those. From the Django projects that I have inherited at least.

Re: Django 3.1

#116

Post by kumarvvr »

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?

Once you have an app deployed, it takes a life of its own. Absolutely, the whole stack matters a lot.

Re: Django 3.1

#117

Post by est »

konschubert wrote: post #4

Slightly OT: How does HN feel about the recent craze to make web python asynchronous? To me, the performance gains are dubious in many cases and the complexity overhead of handling cooperative multitasking just seems like a step back for a language like python.

uWSGI with Gevent patched works far better than async/await.

Re: Django 3.1

#118

Post by formerly_proven »

SahAssar wrote: post #111
collyw wrote: post #104

Earlier quoted context omitted.

EAV is considered an antipattern. While wouldn't rule out using it, it probably means it should be avoided if there is another solution.

I've been working on a project using schema.org objects (100's of types of objects) in postgres in a graph/tree like structure. While structured the objects are not consistent enough for me to want separate schemas for them. Using JSONb in postgres allows me to index separate fields within the JSON while still having all the objects in a single graph. If I couldn't use JSONb with indexes (and triggers for custom fore…

I used to believe in these database antipatterns (e.g. avoid EAV, avoid attribute tables, avoid denormalization, avoid overnormalization, avoid inheritance, avoid wide tables, only use synthetic keys, only use natural keys, never use autoincrement, always use autoincrement), but these days I'm almost certain all of them are wrong, because they are independent of business domain needs. Business domains have antipatterns for their data, data in general decidedly does not. For example, storing physical addresses is subject to a number of antipatterns, including stuff like "natural keys are not a good idea for this".

GP cited EAV as an antipattern, yet it is one of the most reasonable approaches to user-defined fields (especially when suitably augmented), which are frequently a business requirement.

Re: Django 3.1

#119

Post by true_religion »

bzb3 wrote: post #67
danpalmer wrote: post #42

Earlier quoted context omitted.

90% of the time I don't want it. Database, cache, etc, not really that bothered. Web requests take 100-300ms to complete, tying up a worker for 300ms isn't much of a problem. 10% of the time I'm calling an API that takes 3s and tying up a worker for 3s _might_ be a problem. Being able to not do that would be really handy sometimes. Not web servers, but I also do a lot of web scraping and Python is definitely the best…

Web requests taking over 100 ms is an absolute shame that slow languages like python are enabling.

So two examples off the top of my head where it’s the request latency and not python at fault

1. In an incident database, we allow full text search with filtering. Depending on the complexity of the query, and contents of the database this can take 10ms or 10,000ms. This isn’t something easily changed. It’s Lucerne's fault.

2. Querying the physical status of a remote site has variable latency because the sensors are on Wifi and it’s flakey. We can’t easily move the sensors, or make wifi coverage in some warehouse perfect.

Right now, we circuit break and route potentially slow requests to their own cluster via the router, but it’s a poor solution.

Re: Django 3.1

#120

Post by formerly_proven »

OJFord wrote: post #36
formerly_proven wrote: post #35

Earlier quoted context omitted.

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

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

Post reply on HN