I believe issue #28297 is related to the problem described above.
https://code.djangoproject.com/ticket/28297
--
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 dj
On Sunday 11 June 2017 14:41:22 Miika Huusko wrote:
> 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
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
@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
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 nee
@Alceu Rodrigues de Freitas Junior, there are no too basic questions to ask
:) I'm sure I'm missing something, so, please keep asking. But yes, I have
considered that.
@Melvyn Sopacue, I opt to use prefetch_related because I'm fetching "Items"
that are used as ForeignKey for "Photos" and "Event
On Sunday 11 June 2017 09:15:09 Miika Huusko wrote:
> Thanks for response!
>
> Yep, timing with "time" is not the best way to go to compare SQL query
> times. The reason I added that "time" test is that in Stack Overflow
> I was asked to confirm that data transfer is not factor here. I timed
> SQL
This may be very basic thing to ask, but there is no harm to double
check: are you using select_related instead of all for those two
specific Models?
Check out
https://django-debug-toolbar.readthedocs.io/en/stable/index.html if you
aren't using it yet, it will help you to get that very easily
Thanks for response!
Yep, timing with "time" is not the best way to go to compare SQL query
times. The reason I added that "time" test is that in Stack Overflow I was
asked to confirm that data transfer is not factor here. I timed SQL queries
with "EXPLAIN ANALYZE" and "\timing" first. That do
Besides, you "time" from a shell is not the appropriate way to measure
DB response. Try to use whatever is available for your database to
measure that.
Also, see
http://blogs.perl.org/users/steffen_mueller/2010/09/your-benchmarks-suck.html.
Don't be fooled by the article being on a Perl relat
There is some overhead by using ORM: this is inevitable.
On the other hand, you didn't posted your ORM calls, and the queries are
incomplete.
If you think your queries are optimized (as I understand they are from
your description), an workaround is to avoid using the ORM for those
specific q
I have a performance problem with Django + Django REST Framework. The
problem is that it takes Django very, very long time to handle SQL query
response + DRF serialization take quite some time also. It happens when
there are ManyToMany or OneToMany relations and nested objects. Sounds like
"N +
Thanks melvyn. I think you nailed it for me.
Thanks again
Yingi Kem
> On 11 Jun 2017, at 1:18 PM, Melvyn Sopacua wrote:
>
> On Sunday 11 June 2017 05:00:19 yingi keme wrote:
> > I want to know if django supports any real time
> > notifications/communications in web applications.
> >
> > For in
Thanks Andreas. I will check it out
Yingi Kem
> On 11 Jun 2017, at 1:08 PM, Andréas Kühne wrote:
>
> Hi,
>
> You should check out django-channels
> (https://channels.readthedocs.io/en/stable/) for that. That is a websocket
> based solution for doing realtime notifications (as long as the use
On Sunday 11 June 2017 05:00:19 yingi keme wrote:
> I want to know if django supports any real time
> notifications/communications in web applications.
>
> For instance, if User A makes an update to its model instance, User B
> should get an instant notification in real time.
>
> Does django prov
Hi,
You should check out django-channels (
https://channels.readthedocs.io/en/stable/) for that. That is a websocket
based solution for doing realtime notifications (as long as the users are
logged in to the website).
Regards,
Andréas
2017-06-11 14:00 GMT+02:00 yingi keme :
> I want to know if
I want to know if django supports any real time notifications/communications in
web applications.
For instance, if User A makes an update to its model instance, User B should
get an instant notification in real time.
Does django provide a mechanism for that?
--
You received this message becau
17 matches
Mail list logo
