Re: Web based movie app

[Ferran Jovell]

Hi Arshad,

This is a mailing list for the development of django itself, not its uses.
For questions about on how to use the framework, you should check the
django-users mailing list.

Cheers.

Missatge de Arshad Noman  del dia dj., 5 de maig
2022 a les 18:54:

> Is this the wrong mailing list for this post given below or fine?
>
>
>
> I want to make a web-based movie app in Django with data already given in
> a JSON file. The first page will be movie listings and the second page for
> details separate from other movie details means each movie details on a
> separate page. A JSP search bar is also required on top to search movies.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1c9dd6e7-261c-4c71-9b37-6c27870d2f7en%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKh-smHQdkE4FzjrzZUjER8iKW25Ph_y2PYCG0rAynEctAj4Q%40mail.gmail.com.

Re: Performance does not scale when increasing file upload sizes

[Ferran Jovell]

This is still the wrong place. Try django-users mailing list.

El dc., 11 de maig 2022, 17:53, 'Noxx' via Django developers (Contributions
to Django itself)  va escriure:

> Story
>
> Our application supports many file uploads.
> In normal circumstances, those files are only a few megabytes to of around
> 100MB.
> However, some uploads can be several GB in size (10-15GB and up).
>
> I know, that file uploads with such a size can be handled differently,
> e.g. using a seperate endpoint, allowing slow requests to be served
> seperately from the application etc.
> and only to reference those files in a final request.
> This solution would introduce some other problems regarding house-keeping,
> non-atomic requests etc, thus I want to ignore this workaround for now.
> Performance impact:
> 
>
> The impact can be best observed when uploading a file which is bigger in
> it's size, e.g. 1GB+.
> On my maschine it takes the client around 700ms to send the request to the
> application, but than waits around 1.5s for the final response.
> Of course, those numbers are dramatically influenced additionally in
> production by storage speed, file size, webserver (uvicorn/daphne/..),
> load-balancers etc.
> But the final take here is, that the server does some additional work
> after the client finished its request.
> In a production-like environment the numbers peaks to 4s (send request)
> and 16s (waiting for response) for the same file size. Uploading a 3GB
> file, the numbers are 11s and 44s.
> As you can see, the 44s are very near the default gateway timeout of Nginx
> and the hard-coded one of AWS load-balancers.
> As soon as the server needs more than 60s to create the response, the
> client will get a gateway timeout error.
> Workflow of file uploads:
> 
>
> I'm not a Django-dev, so please correct me if I'm wrong. As far as I
> understand, the uploaded file is processed as the following:
>
> Given, that the application is running within an ASGI server, the whole
> request is received by the ASGIHandler.
> It's method #read_body creates a SpooledTemporaryFile.
> This temporary file contains the whole request body, including POST
> parameters and files.
>
> As soon as the request has been received (this is the point the client
> finished uploading the file) it is than transformed into an ASGIRequest.
> The ASGIRequest has #_load_post_and_files and #parse_file_upload as
> methods which parses the body into seperate files.
> This is done by reading the body (the temporary file) and iterating over
> them seperated by the POST seperator done by MultiPartParser.
> The generated chunks are than sent to upload handlers which process those
> files further on using #receive_data_chunk.
> The default upload handlers provided by Django will write those files to
> disc again, depending on their size.
> Problem 
>
> The problem here is, that the uploaded file(s) are transformed and written
> as well as read multiple times.
> First the whole body is written into a SpooledTemporaryFile which is
> re-read using streams (LazyStream) just to be written once more by an
> upload handler.
>
> The impact is low if the uploaded file is small, but increases
> dramatically if the size is increased, the file hits the disc and/or the
> storage is slow.
> Optimization / Brainstorming
> 
>
> Would it be possible to reduce the workflow to a single write call?
> E.g. if the ASGIHandler already splits the request body into seperate
> files, it would be possible to just forward the file pointers until the
> upload handlers needs to be called.
> Those handlers would be able to either use those files as-is or to re-read
> them if pre-processing is needed.
>
> In a best-case scenario, an user uploads a file whichis created as a
> temporary file in parallel.
> As soon as the request has been finished, the file is than moved to its
> final location (as already implemented by upload handlers by providing
> #temporary_file_path)
> The server would not need any time processing the request further on and
> would be able to sent the response within some milliseconds independent of
> the file size.
> The roundtrip time would be reduced by 2/3 and also the gateway timeout
> would be fixed.
> Environment 
>
> We're using Django 4.0.4 with Gunicorn 20.1.0 and Uvicorn 0.17.6.
> Attachments 
>
> I've attached two flame graphs of a file upload which hopfully illustrates
> this issue.
> One is using the internal runserver (wsgi) and one of our (stripped)
> application using gunicorn+uvicorn (asgi)
>
> Final notes
>
> I'd by happy to get some thoughts and opinions on this issue and if this
> is even possi

Re: RE : Email on App

[Ferran Jovell]

Hi Arun,

This is the wrong mailing list to ask this question. This is the mailing
list for the actual development of django. Instead, I think you are looking
for django-users mailing list.

Cheers.

El dl., 4 de jul. 2022, 22:47, Arun  va escriure:

> Hai ,
>
> i am have requirement , user need to send email after login into app with
> login user email
>
> where  , i tried to send with default but i need to use from email as
> login user email
> can any one clear my issue.
>
> Thanks
> Arun
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/44e4b31e-5933-46de-a713-9aa8d0e33fe3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKh-smND2w18JQY1Mw4hFadzwFfixz1aAWVSpHE_duJ3uNvKg%40mail.gmail.com.

`call_command` raises ValueError during testing

[Ferran Jovell]

Hello everyone,

I was working on a admin command today, and when setting up tests and
fixtures for running the command during testing I found this error:

Traceback (most recent call last):
  File "/home/fjm/code/django-stuff/tutorial/polls/tests.py", line 10, in
test_command_output
call_command("closepoll", poll_ids=1, stdout=out)
  File
"/home/fjm/.local/share/virtualenvs/tutorial/lib/python3.10/site-packages/django/core/management/__init__.py",
line 168, in call_command
parse_args.append(min(opt.option_strings), default=0)
ValueError: min() arg is an empty sequence

However, what is weird is that when run from with the manage.py script,
everything seems to be working just fine.

This is the command code

from django.core.management.base import BaseCommand


class Command(BaseCommand):
def add_arguments(self, parser):
parser.add_argument("poll_ids", nargs="+", type=int)

def handle(self, *args, **options):
pass

And this is the test code:
from io import StringIO

from django.core.management import call_command
from django.test import SimpleTestCase


class ClosepollTest(SimpleTestCase):
def test_command_output(self):
out = StringIO()
call_command("closepoll", poll_ids=1, stdout=out)
self.assertIn("Expected output", out.getvalue())

I set up a repo with the minimal code to reproduce this:
https://github.com/mrswats/django-polls-test
Is this a bug? Am I doing something wrong? Have I missed anything?

I checked the bug tracker but could not find anything related to this and
before opening an issue I figured I'd ask. If it is indeed a bug I will
happily write a ticket in the tracker.

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKh-skbGsRO7%2B1H9CBJQEsztwhTUTMus8vuTkQQUUvmXMAj0w%40mail.gmail.com.

Re: `call_command` raises ValueError during testing

[Ferran Jovell]

Hi Tim,

As far as I understand, when adding an argument with `argparser` without
dashes, argparse interprets it as a positional argument and not an option,
which is how it works when you call it from the terminal.
However, calling `call_command` with args instead of keyword arguments
seems to skip that step, so thanks!

And checking again the documentation for call_command it is true that the
examples reflect that although this error message is indeed very obscure.
How can we improve this error reporting on the code side so that it's not
as obscure?

Thanks a lot,

Ferran

Missatge de Tim Graham  del dia dg., 2 d’oct. 2022 a
les 21:39:

> Hi Ferran,
>
> It looks like opt.option_strings is empty because "poll_ids" (in
> parser.add_argument()) isn't prefixed with a dash or double dash.
>
> You could instead use call_command() like this: call_command("closepoll",
> 1)
>
> But I think your invocation could be fixed (or at least not fail so
> obscurely).
> On Sunday, October 2, 2022 at 7:49:26 AM UTC-4 Ferran Jovell wrote:
>
>> Hello everyone,
>>
>> I was working on a admin command today, and when setting up tests and
>> fixtures for running the command during testing I found this error:
>>
>> Traceback (most recent call last):
>>   File "/home/fjm/code/django-stuff/tutorial/polls/tests.py", line 10, in
>> test_command_output
>> call_command("closepoll", poll_ids=1, stdout=out)
>>   File
>> "/home/fjm/.local/share/virtualenvs/tutorial/lib/python3.10/site-packages/django/core/management/__init__.py",
>> line 168, in call_command
>> parse_args.append(min(opt.option_strings), default=0)
>> ValueError: min() arg is an empty sequence
>>
>> However, what is weird is that when run from with the manage.py script,
>> everything seems to be working just fine.
>>
>> This is the command code
>>
>> from django.core.management.base import BaseCommand
>>
>>
>> class Command(BaseCommand):
>> def add_arguments(self, parser):
>> parser.add_argument("poll_ids", nargs="+", type=int)
>>
>> def handle(self, *args, **options):
>> pass
>>
>> And this is the test code:
>> from io import StringIO
>>
>> from django.core.management import call_command
>> from django.test import SimpleTestCase
>>
>>
>> class ClosepollTest(SimpleTestCase):
>> def test_command_output(self):
>> out = StringIO()
>> call_command("closepoll", poll_ids=1, stdout=out)
>> self.assertIn("Expected output", out.getvalue())
>>
>> I set up a repo with the minimal code to reproduce this:
>> https://github.com/mrswats/django-polls-test
>> Is this a bug? Am I doing something wrong? Have I missed anything?
>>
>> I checked the bug tracker but could not find anything related to this and
>> before opening an issue I figured I'd ask. If it is indeed a bug I will
>> happily write a ticket in the tracker.
>>
>> Thanks in advance.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/da3b35c5-eaed-49e8-9b61-eec4b3fc4736n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/da3b35c5-eaed-49e8-9b61-eec4b3fc4736n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKh-smsjaO9pKvHXrYM5e61REn8sj%2BD0qcws7h_rYxQUsaRcQ%40mail.gmail.com.

Re: building a payment app

[Ferran Jovell]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Ferran

Missatge de Music Fm  del dia dc., 28 de des. 2022 a les
20:23:

> hi everyone, thank your for accepting me.
> so i am building a payment gateway and i am stuck on how to integrate the
> cards in the views in django. can anyone help me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/34486f46-fa16-40fd-b356-97b82f2f379en%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKh-sndApxo4wHPXUJB1cG5hn3pEGJjugUWDyfZb%3DJ4P0ocnw%40mail.gmail.com.

Re: Apache and mod_wsgi

[Ferran Jovell]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Ferran

Missatge de pankaj palmate  del dia dg., 1 de
gen. 2023 a les 22:10:

> Hi i am using Apache with mod_wsgi.i want to serve 5000 users at a
> time.how many processes and threads should I use in order to serve 5000
> connections concurrently...in wsgi daemon process ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAPyMU1LVzug7RAXR4TC52TEpUjWZeyAsTYyYavaDPK7yttNZRA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKh-skrAqL2DLteyjYrdcKBRpfvbSiNmpdJZBJ3hRQNLSdQkg%40mail.gmail.com.