Custom models #42
Custom models #42
Conversation
This is still WIP.. gonna try to solve the odd setuptools failure in tests. |
@@ -7,3 +7,4 @@ django-contrib-comments==1.7.3 | |||
django-comments-xtd==1.6.3 | |||
requests | |||
lxml | |||
six |
bufke
Mar 20, 2017
Contributor
What are we using six for? Is it really needed?
What are we using six for? Is it really needed?
""" | ||
A context manager that temporarily sets a setting and reverts to the original value when exiting the context. | ||
""" | ||
return blog_override_settings(**kwargs) |
bufke
Mar 20, 2017
Contributor
Can you explain more about what this is doing? Overriding settings I suppose? But I don't see it used elsewhere in the test.py.
Can you explain more about what this is doing? Overriding settings I suppose? But I don't see it used elsewhere in the test.py.
benjaoming
Mar 20, 2017
Author
Contributor
Wow, Github was confused by my force-push there.. first time I ever tried anything weird on pip. I was responding to your comment on previous, overwritten commit:
What are we using six for? Is it really needed?
Wow, Github was confused by my force-push there.. first time I ever tried anything weird on pip. I was responding to your comment on previous, overwritten commit:
What are we using six for? Is it really needed?
benjaoming
Mar 20, 2017
Author
Contributor
Can you explain more about what this is doing? Overriding settings I suppose? But I don't see it used elsewhere in the test.py.
Yes, it's called by self.settings
many places.
It's necessary to reload blog.settings
when changing django settings. This is a common pattern because the override_settings
context manager only changes and reloads django.conf.settings
Can you explain more about what this is doing? Overriding settings I suppose? But I don't see it used elsewhere in the test.py.
Yes, it's called by self.settings
many places.
It's necessary to reload blog.settings
when changing django settings. This is a common pattern because the override_settings
context manager only changes and reloads django.conf.settings
After trying to implement this and playing around with various proxy and abstract models, I've concluded that it's not possible to implement this without renaming either the model which to access (the one proxying for custom settings) or renaming/moving the default database table and its accessor model (because otherwise it will name collide with the proxy model). To put it shortly, we can't have a concrete model If we want to use So what I came up with is to not reinvent the wheel and instead opt for this: https://pypi.python.org/pypi/swapper Because Django's swappable API is considered undocumented and subject to change (although it hasn't changed for quite some time), it's probably safer to go through an application that implements whatever Django uses internally. Closing this and trying a new PR with swapper instead... |
I've edited my explanation a bit, but feel free to ask! |
Just another quick update: I'm still working on this. It looks possible! However, as with |
This fixes #28
Collect all settings in
blog.settings
, add simple documentation notes for settings (notice Sphinx syntax, we should add sphinx for this project soon)Thanks bigtime to @Fantomas42 for the approach used in django-blog-zinnia for loading custom models.