I'm guessing here that REST would not be the appropriate to handle
"large" amounts of data, and probably that's why Melevyn suggested to
use pagination.
If your customer needs such data to be used off-line, I bet that would
be better to generate a file in the appropriate format, compact it and
redirect it to request the file to be downloaded.
For that, you could skip the ORM entirely, or build an appropriate Model
for it. I would stick with the former (and export the data straight from
the DB with a stored procedure), I don't see you reusing this new Model
in other places in your Django app.
Em 11/06/2017 18:41, Miika Huusko escreveu:
@Melvyn Sopacua, yes, that is very true that auth_user SELECT can be
avoided. Thanks for pointing that out! I don't know what I had put it
like that. Unfortunately, it's the related sets and big JOINs that are
the problem and generating the "slowness".
The reason I'm providing all "Items" and other relates stuff with one
request is that I want to make customer (that's also me and my good
frieds) life easier. I want to keep all the difficult and heavy work
on server side. Customer needs all data because of offline
requirements and therefore would need to loop through pagination or
perform the same big JOIN if "Photos" and other related objects would
be requested separately. Doing that in mobile devices is going to take
longer than on Ubuntu server even if it takes longer that I would
expect with Python + Django. That said, it's good to point out
opinions on design patterns. I haven't listed all background
information for decisions.
I'm not quite sure what you mean by "hash photos and use that as
identifier". What I could do - and believe what you mean(?) - is to
provide list of "Photo" IDs (or hashes) for "Item" and ask customer to
fetch "Photo" details separately with another request(s). Or - easier
for API - leave "Photo" IDs out of the "Item" information completely
and ask customer to make the JOIN with separately requested "Photos".
JOIN could be done with hashes or IDs. Either way it would be customer
who would make the JOIN.
I might go there, but still I don't believe that Django could not
handle my meager data faster than 20 seconds :) If that would be the
case it really would be sad.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/db9cf163-6ddb-db87-e246-1151b180f9cd%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
