Oh, looks like django-hosts also has this problem. It looks like in some
cases the URLs will be correct (due to the PARENT_HOST setting, I think,
which is 'djangoproject.dev:8000' in the djangoproject.com dev settings),
but if you are browsing a different host (e.g. the docs site), then those
URLs use the value from the Site model.
Another thought: 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'},
...
}
That would solve the portability issue, I think, since you could easily
override the necessary parts in development settings. Not sure if it'd be
palatable to deprecation the models though. I don't think maintaining both
versions would be worthwhile in the long run.
On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>
> On 25 janv. 2016, at 14:19, Tim Graham <[email protected] <javascript:>>
> wrote:
>
>
> I believe it's a common use case to import a copy of a production database
> and examine it locally -- that's what I meant about portability.
>
>
> I’m not convinced by this argument because the data for the Site model
> will be wrong anyway in this situation. Or did I miss something?
>
> --
> 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 [email protected].
To post to this group, send email to [email protected].
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/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
