Skip to content
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

Merged
merged 17 commits into from
Jun 30, 2017
Merged

Conversation

KaczuH
Copy link
Contributor

@KaczuH KaczuH commented Jun 21, 2017

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 use config.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.

Kamil Niski added 4 commits June 21, 2017 14:09
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.
@ConorMcGee
Copy link

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.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 96.627% when pulling b2f0774 on KaczuH:KN/settings_rewrite into e10d916 on sunscrapers:master.

@KaczuH
Copy link
Contributor Author

KaczuH commented Jun 21, 2017

This is whole point of this rewrite. Current settings interface is in no way resembling django practices

@pawelswiecki
Copy link

Why merge_settings_dicts was there is the first place?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.6%) to 95.714% when pulling ca7af88 on KaczuH:KN/settings_rewrite into e10d916 on sunscrapers:master.

return user
if config.SEND_ACTIVATION_EMAIL:
validated_data.update({'is_active': False})
return User.objects.create_user(**validated_data)
Copy link
Member

@haxoza haxoza Jun 23, 2017

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}) 👏

user.is_active = False
user.save(update_fields=['is_active'])
return user

Copy link
Member

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)

@haxoza
Copy link
Member

haxoza commented Jun 23, 2017

@pawelswiecki good catch! merge_settings_dicts was there in order to allow djoser users easy default settings overriding. After current changes what user should do if she/he wants to change only one serializer?

@KaczuH
Copy link
Contributor Author

KaczuH commented Jun 23, 2017

@haxoza Overriding settings is not changed from user perspective. Just define

DJOSER = { 'SERIALIZERS': { 'user': <user_custom_serializer> } }

And only this one serializer is overriden default settings are intact.

@coveralls
Copy link

coveralls commented Jun 23, 2017

Coverage Status

Coverage decreased (-0.6%) to 95.745% when pulling 2691082 on KaczuH:KN/settings_rewrite into e10d916 on sunscrapers:master.

self._wrapped = Settings(default_settings, explicit_overriden_settings)


config = LazySettings()
Copy link
Contributor

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?

Copy link
Member

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?

Copy link
Contributor

@pszpetkowski pszpetkowski Jun 23, 2017

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

Copy link
Member

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?

Copy link
Contributor Author

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.

@pszpetkowski
Copy link
Contributor

@mcgeeco care to elaborate what exactly is wrong with idea provided in this PR?

@ConorMcGee
Copy link

@piotr-szpetkowski No I see what the idea is now, it makes sense - I mainly thought it wasn't useful to go from settings to config as people might be used to looking for settings when they're overriding things.

@haxoza
Copy link
Member

haxoza commented Jun 23, 2017

See also #155

@coveralls
Copy link

coveralls commented Jun 23, 2017

Coverage Status

Coverage decreased (-0.8%) to 95.519% when pulling 85c73b2 on KaczuH:KN/settings_rewrite into e10d916 on sunscrapers:master.

Copy link
Contributor

@pszpetkowski pszpetkowski left a 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.

self._wrapped = Settings(default_settings, explicit_overriden_settings)


config = LazySettings()
Copy link
Contributor

@pszpetkowski pszpetkowski Jun 23, 2017

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

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.')
Copy link
Contributor

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?

Copy link
Contributor Author

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

except KeyError:
raise ImproperlyConfigured('Missing settings: DJOSER[\'{}\']'.format(key))
return getattr(config, key)
except ArithmeticError:
Copy link
Contributor

@pszpetkowski pszpetkowski Jun 23, 2017

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.

@coveralls
Copy link

coveralls commented Jun 26, 2017

Coverage Status

Coverage decreased (-0.8%) to 95.632% when pulling 9f4e073 on KaczuH:KN/settings_rewrite into 923a0f9 on sunscrapers:master.

@coveralls
Copy link

coveralls commented Jun 30, 2017

Coverage Status

Coverage decreased (-0.3%) to 96.092% when pulling d7ecd3c on KaczuH:KN/settings_rewrite into 923a0f9 on sunscrapers:master.

@coveralls
Copy link

coveralls commented Jun 30, 2017

Coverage Status

Coverage increased (+0.3%) to 96.782% when pulling 0527246 on KaczuH:KN/settings_rewrite into 923a0f9 on sunscrapers:master.

Copy link
Contributor

@pszpetkowski pszpetkowski left a 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.

@pszpetkowski pszpetkowski merged commit 7442eb7 into sunscrapers:master Jun 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants