HTTPS on development enviroment

I have started using Django and I wanted to integrate social authentication with Google so i had to create self certificates using django_extensions so i test the the authentication with https but when i open localhost it keeps loading without showing the results

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BQTkb%2B%2Bhh_-kmOfHPCvDyL4Z%3DKV_G-sdxjRbybNxavHwGPn8g%40mail.gmail.com.

Re: Eliminating inter-request race conditions

Hello,

Am 31.12.21 um 11:31 schrieb Nick Farrell:
> Correct. To be clear, I am not advocating this behaviour by default, but making it as seamless as possible to enable when required, rather than needing to attempt to hand-roll safe locking semantics each time it's needed.

Thanks for the clarification! It just confused me a bit because this approach seems to be complementary (or even barely related) to the other aspects.

> Certainly there is increased complexity. For the websites I am involved in (primarily health-related ones), if I don't end up providing a django-based solution, product owners end up demanding a SPA-based solution or similar, with the even-greater complexity to the development stack, not to mention testing.

Ahh, a very good point! :-)
But still I wonder if client-side validation and feedback should be optional? That is, if I had to do this myself, I'd hope to find a solution first that works 100 % without client-side effects. This would also help a lot with correctness and testing. Then I'd put all eye candy on top, but keeping it strictly optional.

> if request.method == 'POST':
> form = SomeForm(request.POST, initial=init)
> ...
>
> Note the `initial` parameter: It is used just as it is in the GET request. This allows you to use `form.changed_data` and `form.has_changed()` in form validation.
>
> But where does "init" come from? How can you know what version of the model instance was shown to the user when the form was rendered?

Hmmm. Yes, I see your point...

> There are only two ways I can see of to achieve this: use a full-blown "rowversion" CAS pattern, where there is a dedicated monotonic column on each table which automatically increases with each update, or the method I propose/use, where the original form values are provided via the user agent when the form is POSTed.

Then this would have to be temper-proof, wouldn't it?
(e.g. using https://itsdangerous.palletsprojects.com )

It might even be possible to serialize the entire state of the object into a single hidden field and sign it on GET, then check the signature and deserialize on POST. Or maybe, depending on the exact requirements, even the checksum of the old state would be enough in order to detect that something changed between the old version of the model (as it was when the user started editing it) and the current version (at the time the POST request arrives). This would roughly correspond to a version number without requiring an explicit field on the model.

> Gute Rutsch.

Danke gleichfalls! :-)
Thanks, the same to you!

Best regards,
Carsten

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e42bba72-f122-6223-c517-75a8f74bf222%40cafu.de.

Re: Eliminating inter-request race conditions

Good to hear from you Carsten. Thanks in advance for your comments. I'll see what I can address now:

> *2)* Not being able to safely lock a model/queryset beyond the lifetime of the request. 

I don't quite understand this. It sounds like pessimistic locking?

Correct. To be clear, I am not advocating this behaviour by default, but making it as seamless as possible to enable when required, rather than needing to attempt to hand-roll safe locking semantics each time it's needed.

 

> *3)* Not knowing that data has changed on the server until you submit a form.
> *4)* Smarter form validation

Well, this comes at the cost of the complexity to implement this. For me, at least at this time, the cost is much to high to consider this.

Certainly there is increased complexity. For the websites I am involved in (primarily health-related ones), if I don't end up providing a django-based solution, product owners end up demanding a SPA-based solution or similar, with the even-greater complexity to the development stack, not to mention testing. 

 

> *The solutions*
>
> *Enhanced forms*
> - when rendering a form (using e.g. as_p()), alongside the normal INPUT DOM elements, include additional hidden fields which store a copy of each form field's initial value.

I don't think that having hidden fields with the initial values is necessary: In your view, you can initialize the form like this:

if request.method == 'POST':
form = SomeForm(request.POST, initial=init)
...

Note the `initial` parameter: It is used just as it is in the GET request. This allows you to use `form.changed_data` and `form.has_changed()` in form validation.

But where does "init" come from? How can you know what version of the model instance was shown to the user when the form was rendered? There are only two ways I can see of to achieve this: use a full-blown "rowversion" CAS pattern, where there is a dedicated monotonic column on each table which automatically increases with each update, or the method I propose/use, where the original form values are provided via the user agent when the form is POSTed. I guess a third option would be to cache the form values server-side using redis each time a form a served, and provide an ID to it, perhaps even using the CSRF token as the key.

Perhaps I am missing something - if there is a way to retrieve the initial value of the form automatically, I would love to use it.

Regarding formsets, the same applies, I agree it needs to support that, and by embedding the original values into each form in the formset, it should correctly respect those values when the formset is submitted. 

If it's of any assistance, I can push some code and provide some examples for you to try out. The same app I am using now should be quite easy to clone and evaluate. 

Best regards,
Carsten

 

Gute Rutsch.

Nick 

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cafc7989-44de-4035-88d1-c9d010946ed3n%40googlegroups.com.

Re: Eliminating inter-request race conditions

Hi Nick,

I've thought a bit more about this, but it seems that my requirements are different from yours: E.g. I don't need the client-side validation and especially don't want the complexity that goes with it; on the other hand, I need something that also works with formsets, not only with individual forms.

Am 27.12.21 um 06:36 schrieb Nick Farrell:
> *The problems *(from highest to lowest priority)*:*
> [...]
> *2)* Not being able to safely lock a model/queryset beyond the lifetime of the request.

I don't quite understand this. It sounds like pessimistic locking?

> *3)* Not knowing that data has changed on the server until you submit a form.
> *4)* Smarter form validation

Well, this comes at the cost of the complexity to implement this. For me, at least at this time, the cost is much to high to consider this.

> *The solutions*
>
> *Enhanced forms*
> - when rendering a form (using e.g. as_p()), alongside the normal INPUT DOM elements, include additional hidden fields which store a copy of each form field's initial value.

I don't think that having hidden fields with the initial values is necessary: In your view, you can initialize the form like this:

if request.method == 'POST':
form = SomeForm(request.POST, initial=init)
...

Note the `initial` parameter: It is used just as it is in the GET request. This allows you to use `form.changed_data` and `form.has_changed()` in form validation.

Note that the above, i.e. reconstructing the initial values also for POST requests, is useful both for individual forms and even more with multiple forms, i.e. formsets: If for example you edit a list (formset) of appointments, in formset validation you must make sure that the list of appointments has not changed in the meantime (e.g. appointments were not inserted, replaced or deleted).

Best regards,
Carsten

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7236dee6-010d-8d7e-df6c-4c1007043bdc%40cafu.de.

Re: Not sure if I am doing django-paypal correctly

The code is really simple to implement, but I don't think the explanation was intuitive enough.

You would need to create a signal like so

#hooks.py

from django.dispatch import Signal

success_signal = Signal(providing_args=[])

#views.py

from .hooks import success_signal

... # after payment

success_signal.connect(handler_function)

success_signal.send(sender=None, **kwargs)

This assumes that you already have a listener waiting for the signal broadcast, 

Also replace None with your sender (optional), and replace **kwargs with any kwargs you're sending to your listeners. 

Cheers 

On Wed, Dec 29, 2021, 9:23 PM lone...@gmail.com <lonesoac0@gmail.com> wrote:

Hello all,

      I decided to try and accept payments on my web application.  I have chosen the django-paypal application to help me out with this task.  I found a decent walkthrough at: how-to-accept-paypal-payments-on-your-django-application.  I was able to follow everything until the last step of: "6. Setup a listener to detect successful Paypal payments"  I have never really setup any listeners before so I did not know what to do.  I decided to read the Django-PayPal ReadTheDocs and I found a file that looked structurally similar to what I found on the original walkthrough I had found.  It looks like I needed to make a hooks.py file in my project directory.  I have accomplished that, and the ReadTheDocs says: "Remember to ensure that import the hooks file is imported i.e. that you are connecting the signals when your project initializes. The standard way to do this is to create an AppConfig class and add a ready() method, in which you can register your signal handlers or import a module that does this."  This is where I am getting lost.  I am not quite sure what to do.  Does anyone have a better walkthrough or know what I need to do?

Thank you.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d9567663-20fb-4f43-a6c5-131f23497a7bn%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJ4Kmg7mQXtRCh3MCTS-jKVdfoK0ZW5BTc2PLFWTO5142hcyRQ%40mail.gmail.com.

Re: Automatic subdomain for each user

Check out the django-hosts package, the docs are pretty explanatory and easy to use. 

You'd also want to add '.yourdomain' to the allowed_hosts list and it doesn't work with '127.0.0.1' as its harder for if to figure out the sub-domain, if you want to use it on your development server use localhost, e.g mrj.localhost:8000

On Thu, Dec 30, 2021, 12:02 AM Sherif Adigun <adigunsherif@gmail.com> wrote:

I am faced with a requirement where each user is required to use the application under his own subdomain. Whenever a user registers, he gets username.domain.com and he can add staff, manage reports, etc under his subdomain.

What is the best approach to you can suggest please? 

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f330ad74-75c1-4244-ae27-aa6b97717940n%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJ4Kmg7P12reF-DN_uuLg%3DvAn6sb0yu%3DScWUHZ1%2BxeZyHdoJKw%40mail.gmail.com.

Re: Automatic subdomain for each user

Once you have the TLS certificates and routing working, can't you make a tiny piece of middleware which takes the hostname (provided via nginx/apache in a request header) and add an attribute on the request which corresponds to your virtual site?

e.g. (dodgy untested code follows):

def multisite_middleware(get_response): def middleware(request): domain_name = request.META.get('HTTP_HOST', DEFAULT_DOMAIN)

request.my_site = Site.objects.get(id=domain_name) response = get_response(request) return response return middleware

Then anywhere in your code you can access request.my_site for the site-specific data you need.

In addition, if you haven't already, take a look at https://docs.djangoproject.com/en/4.0/ref/contrib/sites/

On Friday, 31 December 2021 at 07:03:44 UTC+11 adigun...@gmail.com wrote:

Thank you for your detailed response. Following your response point by point with few additional googling, it works as expected.

On cpanel:

I created a subdomain called *

Then I chose document root as the main Django root. (This is needed so that letsencrypt can automatically create a certificate.)

Then the routing works seemlessly

Thank you

On Thu, Dec 30, 2021, 7:06 PM Sherif Adigun <adigun...@gmail.com> wrote:

Thank you very much for you guidance. I have been able to make it work using Django-hosts on my local. Still trying to fix it out to work on my shared hosting if possible

On Thu, Dec 30, 2021, 10:29 AM Sherif Adigun <adigun...@gmail.com> wrote:

Thank you @Tim.  Django subdomains looks promising but it's outdated. It uses codes and imports of django< v2  I have checked django-hosts but it looks as if it can be used  for only predefined list of subdomains. Please help clarify this doubt.

Thank you for your time

On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:

On 2021-12-29 15:02, Sherif Adigun wrote:
> I am faced with a requirement where each user is required to use
> the application under his own subdomain. Whenever a user registers,
> he gets username.domain.com and he can add staff, manage reports,
> etc under his subdomain.
>
> What is the best approach to you can suggest please?

Generally this requires

1) configuring your DNS to allow for wildcard domains so that
*.domain.com points at your web server, usually looking something like

*.example.com. 3600 IN A 198.51.100.17

2) setting up your HTTPS certificates. This could be

- involve an ACME-aware Django route (I'm not sure if such a beast
exists)

- configuring an ACME client like certbot to update your
DNS records so that Let's Encrypt can verify that you own the
domain and then grant your a wildcard cert

- use a different CA to obtain a wildcard cert

2b) if you used a more manual method, put the certs in the
appropriate place for your web-server to pick them up

3) configure your web-server front-end/proxy (usually nginx or
Apache, but there are others) to handle the wildcard domains and pass
them through to your Django app or WSGI server or what have you. Make
sure the domain information is passed through in the HTTP_HOST header

4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
extract the intended host-name from the HTTP_HOST header and possibly
make the route reversable so that .reverse() works

5) check your views so that they make use of the HTTP_HOST
information to filter for user-specific information

-tkc


[1] https://django-subdomains.readthedocs.io/en/latest/


[2] https://github.com/jazzband/django-hosts

--
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/CTynQlthabY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7cef164d-0f9c-4ad9-9d2d-18bfcb2d404bn%40googlegroups.com.

Re: Not sure if I am doing django-paypal correctly

Hey man, beggars cannot be choosers!  Thank you!

On Thursday, December 30, 2021 at 1:28:12 AM UTC-5 Yorben Verhoest wrote:

Hello

I'm a Django Noobie and maybe I'm completely wrong about this but in my app named "core", I have a file called apps.py where I register my signals.

I just followed a tutorial as well so I can't yet explain what it does but if I had to guess is just to register the app with my signals.

Just when reading your question it reminded me of this:

If this is wrong info I'll delete this but maybe this helps :)

Regards

On Wednesday, 29 December 2021 at 21:22:46 UTC+1 lone...@gmail.com wrote:

Hello all,

      I decided to try and accept payments on my web application.  I have chosen the django-paypal application to help me out with this task.  I found a decent walkthrough at: how-to-accept-paypal-payments-on-your-django-application.  I was able to follow everything until the last step of: "6. Setup a listener to detect successful Paypal payments"  I have never really setup any listeners before so I did not know what to do.  I decided to read the Django-PayPal ReadTheDocs and I found a file that looked structurally similar to what I found on the original walkthrough I had found.  It looks like I needed to make a hooks.py file in my project directory.  I have accomplished that, and the ReadTheDocs says: "Remember to ensure that import the hooks file is imported i.e. that you are connecting the signals when your project initializes. The standard way to do this is to create an AppConfig class and add a ready() method, in which you can register your signal handlers or import a module that does this."  This is where I am getting lost.  I am not quite sure what to do.  Does anyone have a better walkthrough or know what I need to do?

Thank you.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/db143e07-597c-489a-ace7-9bb5847ef69an%40googlegroups.com.

Re: Automatic subdomain for each user

Thank you for your detailed response. Following your response point by point with few additional googling, it works as expected.

On cpanel:

I created a subdomain called *

Then I chose document root as the main Django root. (This is needed so that letsencrypt can automatically create a certificate.)

Then the routing works seemlessly

Thank you

On Thu, Dec 30, 2021, 7:06 PM Sherif Adigun <adigunsherif@gmail.com> wrote:

Thank you very much for you guidance. I have been able to make it work using Django-hosts on my local. Still trying to fix it out to work on my shared hosting if possible

On Thu, Dec 30, 2021, 10:29 AM Sherif Adigun <adigunsherif@gmail.com> wrote:

Thank you @Tim.  Django subdomains looks promising but it's outdated. It uses codes and imports of django< v2  I have checked django-hosts but it looks as if it can be used  for only predefined list of subdomains. Please help clarify this doubt.

Thank you for your time

On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:

On 2021-12-29 15:02, Sherif Adigun wrote:
> I am faced with a requirement where each user is required to use
> the application under his own subdomain. Whenever a user registers,
> he gets username.domain.com and he can add staff, manage reports,
> etc under his subdomain.
>
> What is the best approach to you can suggest please?

Generally this requires

1) configuring your DNS to allow for wildcard domains so that
*.domain.com points at your web server, usually looking something like

*.example.com. 3600 IN A 198.51.100.17

2) setting up your HTTPS certificates. This could be

- involve an ACME-aware Django route (I'm not sure if such a beast
exists)

- configuring an ACME client like certbot to update your
DNS records so that Let's Encrypt can verify that you own the
domain and then grant your a wildcard cert

- use a different CA to obtain a wildcard cert

2b) if you used a more manual method, put the certs in the
appropriate place for your web-server to pick them up

3) configure your web-server front-end/proxy (usually nginx or
Apache, but there are others) to handle the wildcard domains and pass
them through to your Django app or WSGI server or what have you. Make
sure the domain information is passed through in the HTTP_HOST header

4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
extract the intended host-name from the HTTP_HOST header and possibly
make the route reversable so that .reverse() works

5) check your views so that they make use of the HTTP_HOST
information to filter for user-specific information

-tkc


[1] https://django-subdomains.readthedocs.io/en/latest/


[2] https://github.com/jazzband/django-hosts

--
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/CTynQlthabY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACP0aXhauGv-q4o_UERihQgAH3Ga6wn_MSYXqm8O4SmMfabTqQ%40mail.gmail.com.

Re: Automatic subdomain for each user

Thank you very much for you guidance. I have been able to make it work using Django-hosts on my local. Still trying to fix it out to work on my shared hosting if possible

On Thu, Dec 30, 2021, 10:29 AM Sherif Adigun <adigunsherif@gmail.com> wrote:

Thank you @Tim.  Django subdomains looks promising but it's outdated. It uses codes and imports of django< v2  I have checked django-hosts but it looks as if it can be used  for only predefined list of subdomains. Please help clarify this doubt.

Thank you for your time

On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:

On 2021-12-29 15:02, Sherif Adigun wrote:
> I am faced with a requirement where each user is required to use
> the application under his own subdomain. Whenever a user registers,
> he gets username.domain.com and he can add staff, manage reports,
> etc under his subdomain.
>
> What is the best approach to you can suggest please?

Generally this requires

1) configuring your DNS to allow for wildcard domains so that
*.domain.com points at your web server, usually looking something like

*.example.com. 3600 IN A 198.51.100.17

2) setting up your HTTPS certificates. This could be

- involve an ACME-aware Django route (I'm not sure if such a beast
exists)

- configuring an ACME client like certbot to update your
DNS records so that Let's Encrypt can verify that you own the
domain and then grant your a wildcard cert

- use a different CA to obtain a wildcard cert

2b) if you used a more manual method, put the certs in the
appropriate place for your web-server to pick them up

3) configure your web-server front-end/proxy (usually nginx or
Apache, but there are others) to handle the wildcard domains and pass
them through to your Django app or WSGI server or what have you. Make
sure the domain information is passed through in the HTTP_HOST header

4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
extract the intended host-name from the HTTP_HOST header and possibly
make the route reversable so that .reverse() works

5) check your views so that they make use of the HTTP_HOST
information to filter for user-specific information

-tkc


[1] https://django-subdomains.readthedocs.io/en/latest/


[2] https://github.com/jazzband/django-hosts

--
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/CTynQlthabY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACP0aXjm8Kpdtvef6Aztvp6FmrKLCA7okgFbLFyYUAZ8xrf%3DTw%40mail.gmail.com.

Re: dotenv - django-environ - etc

Hii All, 

I want freelancing projects works

On Wed, 29 Dec 2021, 1:29 am bnmng, <benjamin@bnmng.com> wrote:

Hi everyone,

I can't wrap my mind around why having my settings in a .env file is more secure than having them in a local_settings.py file, or why one of the various methods is better than another as long as you keep your local settings out of your version control.  Any opinions?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2bd1faca-5e79-48cf-950e-81e5c4b6929fn%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMyGuAaYxECJsjCPYAfb45h3_mAS3uswyyrTzAs13rEGQFC6qQ%40mail.gmail.com.

Re: dotenv - django-environ - etc

Thank you for the replies.  I think I'm getting a better understanding of this.  I had been keeping the .env file in the project folder with the settings file, which seemed to offer no extra security  - hardly worth only being able to store settings as strings (using django-environ).  I'll take another look at the options and I'll move .env out of the project

On Tuesday, December 28, 2021 at 7:39:43 PM UTC-5 ber...@autofyle.com wrote:

In all cases below, the .env file will exist outside of the Django project and will be referenced from the settings file. This allows you to customize and secure each environment while automating the whole build.

Developers
Local settings will point tot he location of the .env file.
This file is excluded from git via gitignore.
Developers push to your repo's development branch which updates your development server after passing CI/CD

1. Developer 1 - /developer1Machine/whatever/unique path/.env
2. Developer 2 - /unique path/.env/unique path/.env

Development environment
Developer settings references its own or same .env file path location 
This directory and .env file permissions are secured such that only the process running the web server has access to it and admin. So you may be bale to log on to the server but won't be able to see this file and or directory if you are not allowed to or in the right security group based on your role.

Staging environment

Can be configured like development with staging desired tweaks.
Testing and QA happens here prior to push to production

Production environment
Can be configured like staging.

On Tuesday, December 28, 2021 at 3:41:25 PM UTC-7 Jason wrote:

an env file is basically imported into your OS environment, so you can retrieve them with the same interface.  That means you can easily include that with your build environment, or inject in some other means.  Can't do that with settings.

Also, lets you keep one settings file, and use `os.environ.get()` anywhere you need to, which provides an identical interface.

On Tuesday, December 28, 2021 at 2:58:28 PM UTC-5 bnmng wrote:

Hi everyone,

I can't wrap my mind around why having my settings in a .env file is more secure than having them in a local_settings.py file, or why one of the various methods is better than another as long as you keep your local settings out of your version control.  Any opinions?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7e0271ad-be6b-4036-8edf-b837b842eb43n%40googlegroups.com.

Re: Automatic subdomain for each user

Thank you @Tim.  Django subdomains looks promising but it's outdated. It uses codes and imports of django< v2  I have checked django-hosts but it looks as if it can be used  for only predefined list of subdomains. Please help clarify this doubt.

Thank you for your time

On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:

On 2021-12-29 15:02, Sherif Adigun wrote:
> I am faced with a requirement where each user is required to use
> the application under his own subdomain. Whenever a user registers,
> he gets username.domain.com and he can add staff, manage reports,
> etc under his subdomain.
>
> What is the best approach to you can suggest please?

Generally this requires

1) configuring your DNS to allow for wildcard domains so that
*.domain.com points at your web server, usually looking something like

*.example.com. 3600 IN A 198.51.100.17

2) setting up your HTTPS certificates. This could be

- involve an ACME-aware Django route (I'm not sure if such a beast
exists)

- configuring an ACME client like certbot to update your
DNS records so that Let's Encrypt can verify that you own the
domain and then grant your a wildcard cert

- use a different CA to obtain a wildcard cert

2b) if you used a more manual method, put the certs in the
appropriate place for your web-server to pick them up

3) configure your web-server front-end/proxy (usually nginx or
Apache, but there are others) to handle the wildcard domains and pass
them through to your Django app or WSGI server or what have you. Make
sure the domain information is passed through in the HTTP_HOST header

4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
extract the intended host-name from the HTTP_HOST header and possibly
make the route reversable so that .reverse() works

5) check your views so that they make use of the HTTP_HOST
information to filter for user-specific information

-tkc


[1] https://django-subdomains.readthedocs.io/en/latest/


[2] https://github.com/jazzband/django-hosts

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.com.

Re: Not sure if I am doing django-paypal correctly

Hello

I'm a Django Noobie and maybe I'm completely wrong about this but in my app named "core", I have a file called apps.py where I register my signals.

I just followed a tutorial as well so I can't yet explain what it does but if I had to guess is just to register the app with my signals.

Just when reading your question it reminded me of this:

If this is wrong info I'll delete this but maybe this helps :)

Regards

On Wednesday, 29 December 2021 at 21:22:46 UTC+1 lone...@gmail.com wrote:

Hello all,

      I decided to try and accept payments on my web application.  I have chosen the django-paypal application to help me out with this task.  I found a decent walkthrough at: how-to-accept-paypal-payments-on-your-django-application.  I was able to follow everything until the last step of: "6. Setup a listener to detect successful Paypal payments"  I have never really setup any listeners before so I did not know what to do.  I decided to read the Django-PayPal ReadTheDocs and I found a file that looked structurally similar to what I found on the original walkthrough I had found.  It looks like I needed to make a hooks.py file in my project directory.  I have accomplished that, and the ReadTheDocs says: "Remember to ensure that import the hooks file is imported i.e. that you are connecting the signals when your project initializes. The standard way to do this is to create an AppConfig class and add a ready() method, in which you can register your signal handlers or import a module that does this."  This is where I am getting lost.  I am not quite sure what to do.  Does anyone have a better walkthrough or know what I need to do?

Thank you.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e0fc31ee-dc9d-432b-88cb-ec1ff2dd636fn%40googlegroups.com.

Re: Automatic subdomain for each user

On 2021-12-29 15:02, Sherif Adigun wrote:
> I am faced with a requirement where each user is required to use
> the application under his own subdomain. Whenever a user registers,
> he gets username.domain.com and he can add staff, manage reports,
> etc under his subdomain.
>
> What is the best approach to you can suggest please?

Generally this requires

1) configuring your DNS to allow for wildcard domains so that
*.domain.com points at your web server, usually looking something like

*.example.com. 3600 IN A 198.51.100.17

2) setting up your HTTPS certificates. This could be

- involve an ACME-aware Django route (I'm not sure if such a beast
exists)

- configuring an ACME client like certbot to update your
DNS records so that Let's Encrypt can verify that you own the
domain and then grant your a wildcard cert

- use a different CA to obtain a wildcard cert

2b) if you used a more manual method, put the certs in the
appropriate place for your web-server to pick them up

3) configure your web-server front-end/proxy (usually nginx or
Apache, but there are others) to handle the wildcard domains and pass
them through to your Django app or WSGI server or what have you. Make
sure the domain information is passed through in the HTTP_HOST header

4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
extract the intended host-name from the HTTP_HOST header and possibly
make the route reversable so that .reverse() works

5) check your views so that they make use of the HTTP_HOST
information to filter for user-specific information

-tkc


[1] https://django-subdomains.readthedocs.io/en/latest/


[2] https://github.com/jazzband/django-hosts





--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20211229180928.221f447b%40bigbox.attlocal.net.

Automatic subdomain for each user

I am faced with a requirement where each user is required to use the application under his own subdomain. Whenever a user registers, he gets username.domain.com and he can add staff, manage reports, etc under his subdomain.

What is the best approach to you can suggest please? 

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f330ad74-75c1-4244-ae27-aa6b97717940n%40googlegroups.com.

Not sure if I am doing django-paypal correctly

Hello all,

      I decided to try and accept payments on my web application.  I have chosen the django-paypal application to help me out with this task.  I found a decent walkthrough at: how-to-accept-paypal-payments-on-your-django-application.  I was able to follow everything until the last step of: "6. Setup a listener to detect successful Paypal payments"  I have never really setup any listeners before so I did not know what to do.  I decided to read the Django-PayPal ReadTheDocs and I found a file that looked structurally similar to what I found on the original walkthrough I had found.  It looks like I needed to make a hooks.py file in my project directory.  I have accomplished that, and the ReadTheDocs says: "Remember to ensure that import the hooks file is imported i.e. that you are connecting the signals when your project initializes. The standard way to do this is to create an AppConfig class and add a ready() method, in which you can register your signal handlers or import a module that does this."  This is where I am getting lost.  I am not quite sure what to do.  Does anyone have a better walkthrough or know what I need to do?

Thank you.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d9567663-20fb-4f43-a6c5-131f23497a7bn%40googlegroups.com.

Re: are migrations the same regardless of database type?

Thanks to all for your replies. Using the "sqlmigrate" command, as far as I can see, there are no differences between database types.
I asked this question initially because I was unable to set up postgresql locally. I have solved those issues now and will follow your advice on using the same db type for local and production.
thank you all.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53f29219-d8a8-421a-81e1-666742f882af%40www.fastmail.com.

Re: dotenv - django-environ - etc

In all cases below, the .env file will exist outside of the Django project and will be referenced from the settings file. This allows you to customize and secure each environment while automating the whole build.

Developers
Local settings will point tot he location of the .env file.
This file is excluded from git via gitignore.
Developers push to your repo's development branch which updates your development server after passing CI/CD

1. Developer 1 - /developer1Machine/whatever/unique path/.env
2. Developer 2 - /unique path/.env/unique path/.env

Development environment
Developer settings references its own or same .env file path location 
This directory and .env file permissions are secured such that only the process running the web server has access to it and admin. So you may be bale to log on to the server but won't be able to see this file and or directory if you are not allowed to or in the right security group based on your role.

Staging environment

Can be configured like development with staging desired tweaks.
Testing and QA happens here prior to push to production

Production environment
Can be configured like staging.

On Tuesday, December 28, 2021 at 3:41:25 PM UTC-7 Jason wrote:

an env file is basically imported into your OS environment, so you can retrieve them with the same interface.  That means you can easily include that with your build environment, or inject in some other means.  Can't do that with settings.

Also, lets you keep one settings file, and use `os.environ.get()` anywhere you need to, which provides an identical interface.

On Tuesday, December 28, 2021 at 2:58:28 PM UTC-5 bnmng wrote:

Hi everyone,

I can't wrap my mind around why having my settings in a .env file is more secure than having them in a local_settings.py file, or why one of the various methods is better than another as long as you keep your local settings out of your version control.  Any opinions?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6cd199e7-bd41-41e8-b4e2-30a27d0b93b5n%40googlegroups.com.

Re: are migrations the same regardless of database type?

Migrations are different depending on your DBMS.
Why? Briefly, here are a few reasons :

1. RDBMS or DBMS (Database management system) is a software that organizes the data in a database thus allowing for easy management, administration, retrieval and manipulation of data by users or applications. e.g. Oracle, PostgreSQL, Microsoft SQL Server, MySQL , DB2, Informix and so forth.
2. Database is typically housed within a RDBMS or DBMS. A database is an organized set of logically connected data stored and accessed electronically from a computer system. The information transforms into helpful knowledge, structured and maintained to fit
    user and or application needs. Apart from storing the data itself, a database also keeps the relationships between data points via database normalization rules.
   
3. SQL is the basic query language used to operate all the database management systems. There are minor syntax changes amongst different DBMS, but the basic SQL syntax remains largely the same.
   There are many types of SQL commands largely divided into DDL, DML, DCL, TCL, and DQL. Different DBMSs have their own flavor of SQL. For example T-SQL for Microsoft, PL/SQL for Oracle
   There are also many

Django's Object-Relational Mapper (ORM), enables you to interact with your database, like you would with SQL and without having to really know the nuances between one DBS and the other. But if you switch from one DBMS to the next, you will need to generate and run new migrations each time including configuration data etc and this will be disastrous. You therefore, want to use the same DBMS throughout your environments and stack.

On Tuesday, December 28, 2021 at 10:55:02 AM UTC-7 Jason wrote:

Not exactly.  Migrations try to be generalized across db types, but that doesn't mean that you can be using db-specific features in your models and ORM usage.  Thats one reason its highly, highly recommended to use the same database and version at all layers of your stack.

In other words, if you're using sqlite locally and postgres in deployment, you're opening yourself to the high probability of having to figure something out and finding out that its due to different features in the db.  

On Tuesday, December 28, 2021 at 10:42:56 AM UTC-5 lie...@punkt.de wrote:

As far as I know, the migrations are "Python-Code" in themselves, only
defining which tables change in what way. Only when they are being
applied, this is turned into actual database code.

But you can test this easily by creating migrations and look at them. Or
use e.g. a postgres docker container, if my memory is wrong.

Cheers

Lars

Am 28.12.21 um 16:02 schrieb Anil Felipe Duggirala:
> hello,
> I running an app locally using an SQlite database (I have not been able to set up postgresql locally). I am running the same app in Heroku, using Postgresql.
> If I run "makemigrations" locally, then push those migrations to Heroku (which is using postgresql), will those migrations be applied correctly by just doing "migrate" on Heroku.
> Do the contents of migrations files depend on the database type that is associated to the app when creating the migrations?
> thank you,
>
> Anil F
>
--
punkt.de GmbH
Lars Liedtke
.infrastructure

Kaiserallee 13a
76133 Karlsruhe

Tel. +49 721 9109 500
https://infrastructure.punkt.de
in...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d61f6aa9-30b3-4de4-ada8-2b69bd7468cbn%40googlegroups.com.

Re: Eliminating inter-request race conditions

Thanks for the reference Carsten.

I believe the approach I am taking, regarding optimistic locking, is superior to what is proposed in that thread. Specifically:

- there is no need for a special version field to be added to the model

- because forms only update specific fields in the associated model(s), there is no point in unnecessarily invalidating the form submission if unrelated model fields have been changed in the background; if a form does not show a field to begin with, having its value change would not alter the behaviour a person would make when editing the form.

Really I think this should be a code part of Django: just as you include CSRF protection virtually everywhere, you would be doing this. It is very rare that this feature would be undesired, and many Django developers will be getting burnt by the lack of CAS-like behaviour.

I'll continue to tinker with this either way, if only to use internally, if there isn't general interest.

cheers,

Nick.

On Tuesday, 28 December 2021 at 21:35:09 UTC+11 carste...@cafu.de wrote:

Hi Nick,

maybe this is a case for optimistic locking?
Does the thread at https://groups.google.com/d/msg/django-users/R7wJBTlC8ZM/MIzvYkWyCwAJ help?

Best regards,
Carsten


Am 27.12.21 um 06:36 schrieb Nick Farrell:
> Hi all.
>
> I've been using Django for quite a number of years now, in various ways. Most of the time, I find myself needing to create custom solutions to solve what appears to be a very common problem. 
>
> During the Christmas downtime, I decided to scratch this itch, and am putting together what will hopefully turn into a solution to what I'll describe below. I'm writing this here to get a sense of what the Django community sees in this: is this a niche problem, is it shared by a few others, or is the lack of these features a fundamental overnight in the core Django product?
>
> *The problems *(from highest to lowest priority)*:*
> *
> *
> *1)* a form is rendered, the data is changed by a different task/request, then the form is submitted, overwriting the recent changes.
>
> Whenever models can be modified by multiple users (or even the same user in different windows/tabs of their browser), this can happen. Also, if there are any background processes which can modify the data (e.g. celery, or various data synchronisation services), it's possible.
> In some situations this is no big deal, as the users do not really care, or you know that the latest data would overwrite the previous data anyway. But in general, this is a major risk, particularly when dealing with any health or financial data. 
>
> *2)* Not being able to safely lock a model/queryset beyond the lifetime of the request.
>
> This is related to problem 1, and solving problem 2 may in some circumstances solve problem 1 - but not always. For example, depending on how the lock is implemented, a "rogue" task/request may bypass the locking mechanism and force a change to the underlying data. Also, if a lock is based on a session, a user may have multiple tabs open in the same browser, using the same session state (via shared cookies)
>
> Solving this problem will reduce the chance that when a person does post a form update, that there is any conflict, meaning fewer tears.
>
> *3)* Not knowing that data has changed on the server until you submit a form.
>
> Ideally there would be a means for someone viewing/editing a form to immediately be notified if data changes on the server, obsoleting the current form. This reduces the amount of wasted time is spent completing a form which is already known to be out of sync, and will need to be redone anyway (as long as problem 1 is solved; otherwise, there'll be data loss)
>
> *4)* Smarter form validation
>
> There are three types of missing validation: 
> - the first is that the default widgets do not support even very simple client-side validation. For example, a text field might need to match a regular expression. 
> - the second type is an ability to provide (in the model definition) arbitrary javascript which can be executed client-side to provide richer realtime validation during data entry.
> - the third type involves effectively providing provisional form data to the server, and having Django validate() the form content without actually saving the result. This would allow (for example) inter-field dependencies to be evaluated without any custom code, providing near-realtime feedback to the user that their form is invalid
>
>
> *The solutions*
> This is based on a day or so's experimentation, and I very much welcome any feedback, both in terms of the usefulness of solving these problems in general, as well as suggestion on better ways to solve the problems,  before I go too far down any rabbit holes.
>
> *Enhanced forms*
> - when rendering a form (using e.g. as_p()), alongside the normal INPUT DOM elements, include additional hidden fields which store a copy of each form field's initial value. 
> - when a form is submitted, compare these hidden values against the current value in the database. If any of these do not match, the clean() method can raise a ValidationError, allowing the user to know what has happened, and that they will need to reload the form and try again, with the new stored values.
>
> This solution is minimally invasive. As well as modifying as_p() and friends, a django template tag can also be exposed for those users who are rendering their forms in a different way.
> Note that there is no reliance on additional attributed in the models: the CAS-like checking performed is explicitly on the rendered form fields; it does not matter if other model fields' values have changed, as someone editing the form can neither see these field values, nor will their POSTing modify these other fields' values.
> (I have implemented the above already, for generic model forms using a single model)
>
> *Locking*
> - provide a mixin which can be used on selected models. When used, a view (usually some sort of form view) can attempt to lock() the model. If successful (because it's not currently locked to someone else), only they can perform writes to the model, until the lock expires. 
> - if the lock has expired, anyone (including the user who took out an expired lock) may overate on the model instance.
> - the lock can be configured to either use the standard database ORM, or redis. Redis will be more performant, but should not be a hard requirement
> - there will be pain points associated with using this without the websocket solution, detailed below: there will not be a clean way to maintain the lock, if the time between consecutive requests is greater than the timeout value
>
> *Websocket*
> - provide a model mixin to enable websocket monitoring
> - use Django Channels to expose a websocket consumer
> - provide a templatetag which will include appropriate javascript into a web page to initialise the client connection (if any forms are configured to be monitored)
> - when the client initialises, it detects the form fields (as per the 'Enhanced Forms' solution) and registers the model instance(s) with the server, via the websocket.
> - whenever a monitored instance changes in Django, a signal is raised, pushing notifications to any clients, along with the new values
> - the client can immediately compare the new instance values to the original values on the form (stored in the hidden fields) and can update the widgets directly if required (e.g. setting a CSS class to indicate the input is invalid, and updating the validation message shown alongside that.
>
>
> A final aspect of the solution is the javascript widgets, but I feel my post is already about 5 times too long.
>
> Any thoughts/comments are welcome.
>
> Thanks.
>
> --
> 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...@googlegroups.com <mailto:django-users...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e9d6ee80-19d2-4ca2-aa1b-10daf7217182n%40googlegroups.com <https://groups.google.com/d/msgid/django-users/e9d6ee80-19d2-4ca2-aa1b-10daf7217182n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e8546765-7a51-4d2e-ba89-71e95af111a8n%40googlegroups.com.

Re: dotenv - django-environ - etc

an env file is basically imported into your OS environment, so you can retrieve them with the same interface.  That means you can easily include that with your build environment, or inject in some other means.  Can't do that with settings.

Also, lets you keep one settings file, and use `os.environ.get()` anywhere you need to, which provides an identical interface.

On Tuesday, December 28, 2021 at 2:58:28 PM UTC-5 bnmng wrote:

Hi everyone,

I can't wrap my mind around why having my settings in a .env file is more secure than having them in a local_settings.py file, or why one of the various methods is better than another as long as you keep your local settings out of your version control.  Any opinions?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b55a11a7-f219-4a24-a734-b55fdc255cf9n%40googlegroups.com.

dotenv - django-environ - etc

Hi everyone,

I can't wrap my mind around why having my settings in a .env file is more secure than having them in a local_settings.py file, or why one of the various methods is better than another as long as you keep your local settings out of your version control.  Any opinions?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2bd1faca-5e79-48cf-950e-81e5c4b6929fn%40googlegroups.com.

Re: What it takes to bring web application to a mobile app

Thank you all for your replies.

Best regards,

~Ram

On Wed, Oct 20, 2021 at 9:07 AM Lalit Suthar <sutharlalit.97@gmail.com> wrote:

you can create apis with django-rest-framework and then can use them at all the backends for web and mobile.

On Wed, 20 Oct 2021 at 12:58, Stijn Verholen <sverholen@gmail.com> wrote:

:D

On 19/10/2021 17:28, Planet X wrote:

Hey there all all you Mind-blowing people

i am new in django i am trying to set my view and urls of app and project i tried lots of time it showing errors please help me out to do i want to learn with the help of your 

On Tuesday, October 19, 2021 at 2:31:53 PM UTC+5:30 ram.mu...@gmail.com wrote:

Hi,

We are planning to create a mobile app for our e-commerce web application that is being developed on DJango, Python, VUE Js and we need to keep both mobile and web interfaces but data should be synced seamlessly. Also we don't want responsive design web app in mobile view.

Best regards,
~ Ram
~ 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53d6d752-020f-4df6-a250-44e80f19af58n%40googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/07d765fc-310c-f575-0fb2-07552edae59e%40gmail.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGp2JVHYFkjHZS2%3DO2LpkTYEpnChh43Pad-9G%2BA_UM1GRO46ww%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BOi5F1L-HRFGNEGtp5d1N0gZthAH3-4CKYGYrWTFG7Vp0ardw%40mail.gmail.com.

Re: are migrations the same regardless of database type?

Not exactly.  Migrations try to be generalized across db types, but that doesn't mean that you can be using db-specific features in your models and ORM usage.  Thats one reason its highly, highly recommended to use the same database and version at all layers of your stack.

In other words, if you're using sqlite locally and postgres in deployment, you're opening yourself to the high probability of having to figure something out and finding out that its due to different features in the db.  

On Tuesday, December 28, 2021 at 10:42:56 AM UTC-5 lie...@punkt.de wrote:

As far as I know, the migrations are "Python-Code" in themselves, only
defining which tables change in what way. Only when they are being
applied, this is turned into actual database code.

But you can test this easily by creating migrations and look at them. Or
use e.g. a postgres docker container, if my memory is wrong.

Cheers

Lars

Am 28.12.21 um 16:02 schrieb Anil Felipe Duggirala:
> hello,
> I running an app locally using an SQlite database (I have not been able to set up postgresql locally). I am running the same app in Heroku, using Postgresql.
> If I run "makemigrations" locally, then push those migrations to Heroku (which is using postgresql), will those migrations be applied correctly by just doing "migrate" on Heroku.
> Do the contents of migrations files depend on the database type that is associated to the app when creating the migrations?
> thank you,
>
> Anil F
>
--
punkt.de GmbH
Lars Liedtke
.infrastructure

Kaiserallee 13a
76133 Karlsruhe

Tel. +49 721 9109 500
https://infrastructure.punkt.de
in...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/60d5140c-5126-4317-ac51-beef4030f08dn%40googlegroups.com.

Re: are migrations the same regardless of database type?

As far as I know, the migrations are "Python-Code" in themselves, only
defining which tables change in what way. Only when they are being
applied, this is turned into actual database code.

But you can test this easily by creating migrations and look at them. Or
use e.g. a postgres docker container, if my memory is wrong.

Cheers

Lars

Am 28.12.21 um 16:02 schrieb Anil Felipe Duggirala:
> hello,
> I running an app locally using an SQlite database (I have not been able to set up postgresql locally). I am running the same app in Heroku, using Postgresql.
> If I run "makemigrations" locally, then push those migrations to Heroku (which is using postgresql), will those migrations be applied correctly by just doing "migrate" on Heroku.
> Do the contents of migrations files depend on the database type that is associated to the app when creating the migrations?
> thank you,
>
> Anil F
>
--
punkt.de GmbH
Lars Liedtke
.infrastructure

Kaiserallee 13a
76133 Karlsruhe

Tel. +49 721 9109 500
https://infrastructure.punkt.de
info@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/af8fec05-774c-d007-c2c9-1b99cb6d7d9a%40punkt.de.

are migrations the same regardless of database type?

hello,
I running an app locally using an SQlite database (I have not been able to set up postgresql locally). I am running the same app in Heroku, using Postgresql.
If I run "makemigrations" locally, then push those migrations to Heroku (which is using postgresql), will those migrations be applied correctly by just doing "migrate" on Heroku.
Do the contents of migrations files depend on the database type that is associated to the app when creating the migrations?
thank you,

Anil F

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2f30b97a-745b-459c-a972-56676588ab46%40www.fastmail.com.