Re: Django + Django REST Framework SQL query response handling and serialization is very, very slow - yet not a “N+1” problem

On Sunday 11 June 2017 13:41:55 Miika Huusko wrote:

 

> @Melvyn Sopacue, I opt to use prefetch_related because I'm fetching

> "Items" that are used as ForeignKey for "Photos" and "Events".

> Select_related is meant for cases where you have OneToOne of

> ForeignKey relation (single item) that you need to fetch. If I would

> be fetching "Photos" I would use selected_related to JOIN "Items" in

> SQL level. Now that I have fetching "Items" relations to "Photos" and

> "Events" are "reverse ForeignKey" Many-to-One sets and I need to use

> prefetch_related.

 

You are in part.

But created_by is a foreign key on items, not the other way around.

 

So this:

 

> > django.db.backends: (0.001) SELECT "auth_user"."id", ...

> > everything

> >

> > ... FROM "auth_user" WHERE "auth_user"."id" IN (1, 2, ... some IDs

> > ...);>

 

can be avoided.

 

Last but not least, this is why API's use pagination. If for whatever reason you must provide such a complex model (instead of having the consumer make more API calls for photo's they don't have yet) you paginate, but it's not very flexible and scales bad.

 

The proper desgin pattern here would be to hash your photo's, use that as identifier in the API and put the burdon on the consumer to only request photo's they don't have the ID for yet.

 

This is for example, how Zendesk email attachments.

--

Melvyn Sopacua