Live data from Hacker News

Django 3.1

djangoproject.com

101–110 of 209 posts

Re: Django 3.1

#101

Earlier quoted context omitted.

waitUntilResolved() would wait until the promises are resolved and of course let other code execute meanwhile.

That's an awesome function. Is it multiprocess?

It was pseudocode.

If a function like this exists, it would just sleep until the given promises are resolved. I don't see how that is realted to the term "multiprocess".

Re: Django 3.1

#102
post #10
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.

Can you give some examples where a relational schema isn’t suitable?

Speaking strictly of schema...

Relational schema are flexible and allow for an optimizer to figure out how best to fetch your data based on the data are querying and filtering for and stored statistics about your data set.

Document oriented storage is great when you don't need the optimizer because you already know how the data is written and read. This means you can bundle it up into small, single fetch documents. No statistics or optimizer necessary. This is great if you understand your use cases really well, and they never change (good luck with that) or you have a large distributed data set that would be tough on an analyzer.

Re: Django 3.1

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

Yep - SQLAlchemy's JSONB type is awesome as well. It's made life so much easier for relatively unstructured data!

Re: Django 3.1

#104
post #77

Earlier quoted context omitted.

What’s a real world example where you would choose to index the JSON as you said rather than putting them into the fields/schema.

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.

Re: Django 3.1

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

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 directly into the modelling but there is a draft-7 compliant Python project that you can use for this in the model's clean() method.

Re: Django 3.1

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

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 :)

Re: Django 3.1

#107

Earlier quoted context omitted.

That's an awesome function. Is it multiprocess?

It was pseudocode. If a function like this exists, it would just sleep until the given promises are resolved. I don't see how that is realted to the term "multiprocess".

Well I don't really see how it can exist, do non-blocking io and wait for promises while performing a sleep. So the only way left is multiprocess.

Re: Django 3.1

#108

Earlier quoted context omitted.

It could be done with anything, but async view lets other code execute while it is waiting for IO, what does waitUntilResolved do?

waitUntilResolved() would wait until the promises are resolved and of course let other code execute meanwhile.

It sounds like your waitUntilResolved() function is effectively asyncio.gather(), which due to the nature of Python’s async implementation is not something that could be used in a Django view prior to this release.

Re: Django 3.1

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

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

Post reply on HN