Re: Replacing the contrib.sites Site model with a setting?

Hi all, I'm in favour of defining the sites in settings. In addition, it would ease transferring db dumps from live to test servers and it would prevent db queries. I wonder, because we define sites in ALLOWED_HOSTS as well, whether we can combine these settings. For scheme, what are

Re: Replacing the contrib.sites Site model with a setting?

I don't think its feasible to move away from db model entirely. Widely used packages like django CMS rely on there being a site model. On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham wrote: > > In another thread about adding a "scheme" field to the Site model [1], I > floated the

Re: Replacing the contrib.sites Site model with a setting?

On Sunday 29 January 2017 22:54:12 Proxy wrote: > > Actually django.contrib.settings needs to be SWAPPABLE. Then it will > receive +100. (Oooohh... Someone already proposed this. Even with code > sample -> https://code.djangoproject.com/ticket/22779. 3 years ago and > ticket still open... How

Re: Replacing the contrib.sites Site model with a setting?

+1 for this change. This issue bites our team every time we copy a db from production to dev or stage or local, and certain features break because of the mis-pointed Sites setting. ./s -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Replacing the contrib.sites Site model with a setting?

Followed by https://code.djangoproject.com/ticket/27784 I'm gonna revive this discussion about Sites contrib framework. Let's sum up cases when django.contrib.sites can be used: 1. *Single* django site with totally no use of sites framework. Docs tells us to make a dummy instance

Re: Replacing the contrib.sites Site model with a setting?

What would be the recommendation for assigning content to a particular site in a shared DB model? Integer field with the current SITE_ID to create a sort of faux FK or M2M? Choices? One thing I like about this pattern I haven't seen discussed already is that it would make it far easier to

Re: Replacing the contrib.sites Site model with a setting?

Could we make the sites portion of Django an interface? In settings you give something like SITES_PROVIDER = 'myapp.sites.MultiTenancySite', and that provider then needs to fulfill a given API. This way we wouldn't need to offer anything complex in-built, but users would be free to do whatever

Re: Replacing the contrib.sites Site model with a setting?

This is a valid use case, but not one django.contrib.sites (officially) supports, since it requires a constant SITE_ID setting. While Tim's suggestion doesn't cause a regression, it doesn't make this pattern easier to implement either. It's definitely worth considering. -- Aymeric. > Le 30

Re: Replacing the contrib.sites Site model with a setting?

What if this list of sites needs to be changed dynamically without app restart (multitenancy)? On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham wrote: > In another thread about adding a "scheme" field to the Site model [1], I > floated the idea of moving the data stored by the Site model

Re: Replacing the contrib.sites Site model with a setting?

This is just that I'm doing in django-sites package: https://github.com/niwinz/django-sites . + to have the similar approach in django (sites as settings). On Fri, Jan 29, 2016 at 10:45 PM, Tim Graham wrote: > In another thread about adding a "scheme" field to the Site

Re: Replacing the contrib.sites Site model with a setting?

> On 29 janv. 2016, at 21:45, Tim Graham wrote: > > Do you think we'll be better off in the long run with a setting as opposed to > storing the data in the database? Yes. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django

Re: Replacing the contrib.sites Site model with a setting?

+1 on setting. That's what I've ended up doing on all of my projects anyhowways. On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham wrote: > > In another thread about adding a "scheme" field to the Site model [1], I > floated the idea of moving the data stored by the Site model into a

Replacing the contrib.sites Site model with a setting?

In another thread about adding a "scheme" field to the Site model [1], I floated the idea of moving the data stored by the Site model into a setting: I've sometimes thought that the Site model violates the principle that you shouldn't put configuration in your database. I guess there's some