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 expecte
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 id
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 typi
+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 (Contri
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.
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 exten
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
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 j
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 int
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 model [1], I
> floated th
> 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 developers (Contribut
+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
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
use
13 matches
Mail list logo