Re: Best digital ocean plan for a production server

[Abdul Qoyyuum]

Not sure what you mean. All of those can be in separate docker images to
build (except for 11 and 13) but have to be docker-composed properly. But
since you're moving to Docker images, you can then instead deploy to any
Kubernetes cluster and scale with X number of nodes. Even better if you
want to test and make sure all of the deploy settings work properly each
time with Terraform but that's my opinion.
https://www.digitalocean.com/community/questions/best-practices-to-deploy-docker-on-digitalocean-using-terraform

On Sun, Jul 24, 2022 at 1:22 AM Ram  wrote:

> Thank you all for your input. I would like to sign up for a plan which can
> let us focus only on coding and still scalabile, but my concern is our
> application requires following:
>
> 1. Linux OS
> 2. Postgres
> 3. Python 3.10
> 4. Django latest
> 5. Vue.js
> 6. Gunicorn
> 7. Nginx
> 8. Let's Encrypt or any SSL
> 9. Redis
> 10. Celery
> 11. Github
> 12. Jenkins CI/CD
> 13. Support for API: Stripe, Twillio, Google and etc.
>
> If these can be packaged into a docker image that would be great. I know
> some of them cannot be in Docker image. I'm planning to check this with
> both Digital Ocean and Heroku anyway, but I wanted to understand experts
> advice in this community.
>
> Best regards,
> ~Ram
>
> On Wed, Jul 13, 2022 at 12:24 AM Abdul Qoyyuum 
> wrote:
>
>> I prefer Heroku and deploying Django as a docker image to Heroku. Less
>> maintenance, worry less about server setups and focus more on code than
>> anything else (i.e. serverless). Start with a hobby plan and if able to get
>> customers, then start paying for scalability features.
>>
>> On Sunday, July 10, 2022 at 11:21:00 AM UTC+8 ram.mu...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> We are planning to launch our application in production once all the
>>> testing is completed after deployment to our development server. We are
>>> using Jenkins CI automation to deploy the code to the development server
>>> and we will do the same in production server too, but we are currently
>>> doing a feasibility study to understand which options are good for Django
>>> web application for both Web and Mobile app.
>>>
>>> If anyone in this Django users community is currently on any Digital
>>> Ocean's production server plan, could you share some details and
>>> suggestions.
>>>
>>> Best regards,
>>> ~Ram
>>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/be3bb62c-7ce7-47c6-8bc1-80951927712dn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/C_v8NaMOx4Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CA%2BOi5F0zneD-%2BmKb8dZcV8iu-5pryw2Yt9djnjJisWr6k381ow%40mail.gmail.com
> 
> .
>


-- 
Abdul Qoyyuum Bin Haji Abdul Kadir
HP No: +673 720 8043

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAA3DN%3DW03Tpj%3Dxs61o5cNUCn21bOk2xjXuemArcAG4P0oiChkw%40mail.gmail.com.

Re: Help to implement join query in django orm

[Jitendra kumar Patra]

Ping me 7008080545

On Fri, 22 Jul, 2022, 12:16 Avi shah,  wrote:

> I have two tables
> Tbl 1
> &
> Tbl 2
>
> I need to connect the two tables using a join
>
>
> Thanks and regards,
> Avi shah
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CALa7AFNmoep5MT3MwoYn1ZF0S%3DENPUdVAO-_3EmVyAzCub_Jkg%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAOAROf%3DgMPbSQ37f81A0rpRr7NgiUFF8ZyTsF8bZ-KG9Sgh%3DkA%40mail.gmail.com.

Re: Help to implement join query in django orm

[Abhishek Gupta]

Hey, you have to write custom raw query for join tables which are not
connected with foreign key relationship in django.

On Sun, Jul 24, 2022, 11:17 Lalit Suthar  wrote:

> this can be helpful
>
> https://betterprogramming.pub/django-select-related-and-prefetch-related-f23043fd635d
>
> On Sun, 24 Jul 2022 at 00:30, Ryan Nowakowski  wrote:
>
>> On Fri, Jul 22, 2022 at 12:16:14PM +0530, Avi shah wrote:
>> > I have two tables
>> > Tbl 1
>> > &
>> > Tbl 2
>> >
>> > I need to connect the two tables using a join
>>
>> If these tables were created outside of Django, in other words, not
>> using manage.py migrate, you can use Django's legacy database support to
>> auto generate the models[1].  After that, each table will have a model
>> associated with it.  You can then use Django's ForeignKey support to query
>> the tables.
>>
>>
>> [1] https://docs.djangoproject.com/en/4.0/howto/legacy-databases/
>>
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/20220723185935.GB15838%40fattuba.com
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAGp2JVHauj%2BS47HfmcYOrNQHJk3bTQbtdBm%3DdLRNx_8woM6XwQ%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CABwiCvrSuY6AmBkARJFt%2BaCeR_wFVGf%3DKWdLP227GApDW4AcWQ%40mail.gmail.com.

Re: DRF question

[Ram]

Hi Jason,

Thank you for your email.

1. I'm not sure what you are referring to 'template-based' responses with
RESTFUL?

2. Also we are not looking for extensibility to be smooth. My concern is
why we need to change the existing implementation in user registration when
DRF is a separate package?

3. Let me explain to you why we are adding REST APIs now after completing
all the apps in regular Django. We need to port our whole site to a mobile
app. So to make it compatible for a mobile app, we are adding REST APIs.

Please let me know if this is still doable without changing the user
registration?

Best regards,
~Ram

On Sat, Jul 23, 2022 at 4:28 PM Jason  wrote:

> sure, it can be used to extend, but you're also equating template-based
> responses with restful.  those are pretty differnet paradigims, so you do
> need to account for the different use cases.  there's a reason why DRF is a
> separate package built on top of django, and not in core.  because its a
> pretty significant retrofit.
>
> You can absolutely do regular django and DRF in a same project, it just
> seems that your expecting "extensibility" to be a seamless one to one
> transfer, and that isn't the case.
>
> Also, i think you aren't considering ways to architect this structure.
> ie, have `api/v1/user` deal with HTTP verbs, while having `/user` deal with
> legacy django.  One deals with a DRF endpoint, whther apiview, generic, or
> viewset. your choice.  the second deals with a model form.  you can then
> determine what is the shared functionality between the two that is outside
> the frameworks, and then have your separate handlers call that thing as
> part of their flow.
>
> On Saturday, July 23, 2022 at 1:04:52 PM UTC-4 ram.mu...@gmail.com wrote:
>
>> Hi Jason,
>>
>> Thank you for your email. I expected DRF could be an extensible feature
>> rather than forcing to change existing implementation. Extensibility
>> practice happens in many open source and enterprise projects. That is why
>> I'm shocked to learn this.
>>
>> Best regards,
>> ~Ram
>>
>>
>>
>> On Sat, Jul 23, 2022 at 4:56 AM Jason  wrote:
>>
>>> Ram, what did you expect, to be honest?  Going from forms to rest are
>>> two different implementation details for the same concept.  When you do
>>> such things, you need to evaluate whether the tradeoffs are worth it.
>>>
>>>
>>> On Saturday, July 23, 2022 at 1:30:43 AM UTC-4 ram.mu...@gmail.com
>>> wrote:
>>>
 Hi Thomas & Julio,

 Thank you for your answers, but we are shocked to learn that our user
 registration functionality has to be rewritten again to create REST APIs.
 That means whatever Apps that we developed on User registration have to be
 modified too and this further means that we will have to redevelop our
 whole Apps (6 of them). I still can not believe this?

 I hope someone has a clue about this problem and I'm wondering
 whether anyone ran into this situation as us.

 Best regards,
 ~Ram


 On Wed, Jul 20, 2022 at 10:44 PM Julio Cojom 
 wrote:

> Hi Ram,
>
> Aditional to all the suggestions, please keep in mind django-filters
> as they are important to filter data in your api requests
>
> Regards,
>
> Julio Cojom
>
> El mié, 20 jul 2022 a las 20:37, Michael Thomas (<
> michael.t...@gmail.com>) escribió:
>
>> There's no reason at all that DRF can't be used to do this. Just
>> don't use a viewset, as it's not the right fit for this type of thing.
>> Read through the code for how your current system works, then
>> re-implement the relevant parts as DRF ApiView's.
>>
>> On Thu, Jul 21, 2022 at 8:43 AM Ram  wrote:
>>
>>> Thank you all for quick suggestions.
>>>
>>> We are stuck with implementing the first API, which is login
>>> endpoint. That means since we already developed user registration
>>> functionality before without DRF, there seems no way to create a login
>>> endpoint so that an existing registered user can login using REST API 
>>> and
>>> access his/her respective data . All we are finding on the web is to 
>>> create
>>> an Abstract user using DRF which requires to change the existing user
>>> registration implementation. So I'm wondering whether there is any way 
>>> to
>>> remedify this or are we missing something?
>>>
>>> Best regards,
>>> ~Ram
>>>
>>>
>>>
>>> On Tue, Jul 19, 2022 at 6:30 PM Hella thor 
>>> wrote:
>>>
 Hi Ram
 您可以在原来项目的基础上创建新的APP来单独给移动应用程序来使用，并在整体项目完成以后研究是不是需要DRF来兼容。

 Lalit Suthar  于2022年7月19日周二 19:04写道：

> I would also suggest keeping Django views as it is and writing new
> views for your APIs
> maybe you can create another file named apiviews.py and then write
> new APIs with help of your present views
> refer: https://www.django-rest-framework.org/api-guide/views/

Re: DRF question

[Ram]

Hi Jason,is separ

Thank you for your email.

1. I'm not sure what you are referring to 'template-based' responses with
RESTFUL?

2. Also we are not looking for extensibility to be smooth. My concern is
why we need to change the existing implementation in user registration when
DRF is a separate package?

3. Let me explain to you why we are adding REST APIs now after completing
all the apps in regular Django. We need to port our whole site to a mobile
app. So to make it compatible for a mobile app, we are adding REST APIs.

Please let me know if this is still doable without changing the user
registration?

Best regards,
~Ram

On Sat, Jul 23, 2022 at 4:28 PM Jason  wrote:

> sure, it can be used to extend, but you're also equating template-based
> responses with restful.  those are pretty differnet paradigims, so you do
> need to account for the different use cases.  there's a reason why DRF is a
> separate package built on top of django, and not in core.  because its a
> pretty significant retrofit.
>
> You can absolutely do regular django and DRF in a same project, it just
> seems that your expecting "extensibility" to be a seamless one to one
> transfer, and that isn't the case.
>
> Also, i think you aren't considering ways to architect this structure.
> ie, have `api/v1/user` deal with HTTP verbs, while having `/user` deal with
> legacy django.  One deals with a DRF endpoint, whther apiview, generic, or
> viewset. your choice.  the second deals with a model form.  you can then
> determine what is the shared functionality between the two that is outside
> the frameworks, and then have your separate handlers call that thing as
> part of their flow.
>
> On Saturday, July 23, 2022 at 1:04:52 PM UTC-4 ram.mu...@gmail.com wrote:
>
>> Hi Jason,
>>
>> Thank you for your email. I expected DRF could be an extensible feature
>> rather than forcing to change existing implementation. Extensibility
>> practice happens in many open source and enterprise projects. That is why
>> I'm shocked to learn this.
>>
>> Best regards,
>> ~Ram
>>
>>
>>
>> On Sat, Jul 23, 2022 at 4:56 AM Jason  wrote:
>>
>>> Ram, what did you expect, to be honest?  Going from forms to rest are
>>> two different implementation details for the same concept.  When you do
>>> such things, you need to evaluate whether the tradeoffs are worth it.
>>>
>>>
>>> On Saturday, July 23, 2022 at 1:30:43 AM UTC-4 ram.mu...@gmail.com
>>> wrote:
>>>
 Hi Thomas & Julio,

 Thank you for your answers, but we are shocked to learn that our user
 registration functionality has to be rewritten again to create REST APIs.
 That means whatever Apps that we developed on User registration have to be
 modified too and this further means that we will have to redevelop our
 whole Apps (6 of them). I still can not believe this?

 I hope someone has a clue about this problem and I'm wondering
 whether anyone ran into this situation as us.

 Best regards,
 ~Ram


 On Wed, Jul 20, 2022 at 10:44 PM Julio Cojom 
 wrote:

> Hi Ram,
>
> Aditional to all the suggestions, please keep in mind django-filters
> as they are important to filter data in your api requests
>
> Regards,
>
> Julio Cojom
>
> El mié, 20 jul 2022 a las 20:37, Michael Thomas (<
> michael.t...@gmail.com>) escribió:
>
>> There's no reason at all that DRF can't be used to do this. Just
>> don't use a viewset, as it's not the right fit for this type of thing.
>> Read through the code for how your current system works, then
>> re-implement the relevant parts as DRF ApiView's.
>>
>> On Thu, Jul 21, 2022 at 8:43 AM Ram  wrote:
>>
>>> Thank you all for quick suggestions.
>>>
>>> We are stuck with implementing the first API, which is login
>>> endpoint. That means since we already developed user registration
>>> functionality before without DRF, there seems no way to create a login
>>> endpoint so that an existing registered user can login using REST API 
>>> and
>>> access his/her respective data . All we are finding on the web is to 
>>> create
>>> an Abstract user using DRF which requires to change the existing user
>>> registration implementation. So I'm wondering whether there is any way 
>>> to
>>> remedify this or are we missing something?
>>>
>>> Best regards,
>>> ~Ram
>>>
>>>
>>>
>>> On Tue, Jul 19, 2022 at 6:30 PM Hella thor 
>>> wrote:
>>>
 Hi Ram
 您可以在原来项目的基础上创建新的APP来单独给移动应用程序来使用，并在整体项目完成以后研究是不是需要DRF来兼容。

 Lalit Suthar  于2022年7月19日周二 19:04写道：

> I would also suggest keeping Django views as it is and writing new
> views for your APIs
> maybe you can create another file named apiviews.py and then write
> new APIs with help of your present views
> refer: https://www.django-rest-framework.org/api-guide/views/