Replacing the contrib.sites Site model with a setting?

[Tim Graham]

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 usefulness to having a ForeignKey to the site, but... would it be feasible to offer a SITES setting that could be used instead? e.g.

SITES = {
    1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
    ...
}

Carl said:+1 to this, I've long felt that the Site model was an anti-pattern. I don't know if it's worth deprecating and switching to a different system, though; it'd be a relatively painful deprecation for those using  it, I would guess.

James said:  "In using Marten Kenbeek's URL dispatch rewrite branch, I've found that using the pattern of defining some site configuration in your settings is the way to go: it more easily allows you to have URL patterns on multiple domain/scheme combinations. I use a dict similar to what Tim has shown, and then use it to initialize my scheme/domain URL constraints in my root urls.py."

I'd like to get more feedback and ideas about this. Do you think we'll be better off in the long run with a setting as opposed to storing the data in the database? Maybe writing a new sites app that uses a setting instead of trying to modify the existing models-based one would be a better plan.

I think the hard problem to solve is what to do about the Redirect and FlatPage models which have ForeignKey and ManyToManyField relations to the Site model.

Perhaps some outcome of this discussion plus considering what features of related third-party tools like django-hosts [2] might be useful to incorporate in Django itself would be worthy of a project like Google Summer of Code.

[1] https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
[2] https://github.com/jazzband/django-hosts

[Chris Foresman]

+1 on setting. That's what I've ended up doing on all of my projects anyhowways. 

[Aymeric Augustin]

On 29 janv. 2016, at 21:45, Tim Graham <timog...@gmail.com> 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.

[Andrey Antukh]

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).

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrey Antukh - Андрей Антух - <ni...@niwi.nz>

http://www.niwi.nz

https://github.com/niwinz

[Max Arnold]

What if this list of sites needs to be changed dynamically without app restart (multitenancy)?

[Aymeric Augustin]

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.

> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20160130070141.GA2770%40otg.dm.

[Anssi Kääriäinen]

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 they want to.

 - Anssi

[Tim Baxter]

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 extend Sites as need. For example, one request I've had is the ability to store some additional information on Sites beyond name and domain. This would provide a pretty straightforward mechanism to do so.

[Proxy]

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 anyways... So yeah, It looks like antipattern. +1 for dict settings.
   
2. Fixed django sites that proposed dict in settings would do the job quite easily. +1 for dict settings.
3. Dynamic django sites that implements SaaS? Hay, we're now in 2017 It needs not only more fields bound to Site model than domain and verbose name, but can't relate on server restart to reload dict settings. And whose gonna manually change that settings?! -inf for dict settings, +0 model sites.

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 typical... :/)

In my project I'm case #2, but I still need a bunch of additional fields to provide for Site. Icons, descriptions, https flags. Think with SaaS and you'll know the drill.

Currently making it possible equals ton of hackish lines and definitely more DB queries.

Django needs to squish more juice from sites framework. Even for simple uses - Site query is cached anyways. I agree that majority of django powered sites are using SITE_ID = 1, and making dummy instances can be useless overhead, but replacing sites configuration by static dict settings will totally kill the functionality. Sites, when used, should be dynamic and cached. And remember -> sites can be bound dynamically with request.get_host(), so there is no fixed settings (https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/contrib/sites/models.py#L63).

[Scot Hacker]

+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

[Shai Berger]

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 typical... :/)
>
>
> In my project I'm case #2, but I still need a bunch of additional fields to
> provide for Site. Icons, descriptions, https flags. Think with SaaS and
> you'll know the drill.
>

In that case, and until Site becomes swappable, you should be able to do what
we all did before User was swappable: Define a "SiteProfile" model, with a 1-1
relationship to Site, where you can add fields to your heart's content.

> Currently making it possible equals ton of hackish lines and definitely
> more DB queries.
>

So, could you explain why that is the case?

Shai.

[Robert Singer]

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:

[Wim Feijen]

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 expected values here? As we are moving from http to https environments, I wonder: do we still want to define schemes? I prefer following server configuration here.

Wim