-
Notifications
You must be signed in to change notification settings - Fork 460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kn/settings rewrite #203
Kn/settings rewrite #203
Conversation
merge_settings_dicts was invoked always when settings value was fetched. Recursive, hard to read algorithm is not necessary on such simple task getting value from dict.
For what it's worth, I'm definitely -1 on this. I think it's better to stick with the existing code which more closely resembles established Django patterns. |
This is whole point of this rewrite. Current settings interface is in no way resembling django practices |
Why |
djoser/serializers.py
Outdated
return user | ||
if config.SEND_ACTIVATION_EMAIL: | ||
validated_data.update({'is_active': False}) | ||
return User.objects.create_user(**validated_data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK we cannot get rid of with transaction.atomic():
context manager here because perform_create
method is called by create
method where IntegrityError
is handled. If we do not use separate transaction here then (depending on global django settings) the current transaction (e.g. per request) can be not valid anymore (e.g. for postgres).
See 8a28b76
But in general good idea with shortening the code with validated_data.update({'is_active': False})
👏
djoser/serializers.py
Outdated
user.is_active = False | ||
user.save(update_fields=['is_active']) | ||
return user | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be almost like you did:
with transaction.atomic():
if config.SEND_ACTIVATION_EMAIL:
validated_data.update({'is_active': False})
return User.objects.create_user(**validated_data)
@pawelswiecki good catch! |
@haxoza Overriding settings is not changed from user perspective. Just define
And only this one serializer is overriden default settings are intact. |
djoser/settings.py
Outdated
self._wrapped = Settings(default_settings, explicit_overriden_settings) | ||
|
||
|
||
config = LazySettings() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
config
name seems very un-pythonic to me. Maybe something like djoser_settings
would be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, do we change config
to djoser_settings
or settings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
settings sound good in my opinion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also one more different idea: what about djoser.conf.settings
like Django does django.conf.settings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@haxoza @piotr-szpetkowski djoser.conf.settings
would be the best but it will introduce incompatibility for older versions.
I'll add deprecation warnings and try to keep old interface but it should be dropped in the future.
@mcgeeco care to elaborate what exactly is wrong with idea provided in this PR? |
@piotr-szpetkowski No I see what the idea is now, it makes sense - I mainly thought it wasn't useful to go from |
See also #155 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to change few things. Also it would probably by a good idea to write some tests for new settings and update documentation on settings.
djoser/settings.py
Outdated
self._wrapped = Settings(default_settings, explicit_overriden_settings) | ||
|
||
|
||
config = LazySettings() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
settings sound good in my opinion
djoser/settings.py
Outdated
This function is here only to provide backwards compatibility in case anyone uses old settings interface. | ||
It is strongly encouraged to use dot notation. | ||
""" | ||
warnings.warn('The settings.get(key) is superseded by the dot attribute access.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using deprecation warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@piotr-szpetkowski I'll add PendingDeprecationWarning
djoser/settings.py
Outdated
except KeyError: | ||
raise ImproperlyConfigured('Missing settings: DJOSER[\'{}\']'.format(key)) | ||
return getattr(config, key) | ||
except ArithmeticError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure it's ArithmeticError
? Doesn't make much sense to me.
…N/settings_rewrite
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to merge in my opinion.
I saw a few problems with how we handle settings in Djoser. And decided to try solve some of them.
settings.get("SEND_ACTIVATION_EMAIL")
is cumbersome interface and it is used a lot across the code. We should look for more clear and simpler way. Thats why I decided to useconfig.SEND_ACTIVATION_EMAIL
somewhat resembling how Django does.merge_settings_dicts
was invoked every time an setting value is looked up. This is not optimal. Additionaly djoser settings aren't so complex so why to use this recursive function? I removed it and replaced with simple approach: instantiate default djoser settings and override anything that user customized in django settings.There is some work to do but i want to show this idea for consideration.