-
Notifications
You must be signed in to change notification settings - Fork 25
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
[WIP] Add Support for Django 1.11 and add Python 3 support. #27
Open
WTFox
wants to merge
64
commits into
leandrosouza:master
Choose a base branch
from
stratasan:upstream-support-django1.11-python2or3
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
[WIP] Add Support for Django 1.11 and add Python 3 support. #27
WTFox
wants to merge
64
commits into
leandrosouza:master
from
stratasan:upstream-support-django1.11-python2or3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When loading fixtures, do not trigger audits.
Increased Auditchange old_value and new_value to textfield
Avoid errors when obj_description is > 100 chars.
Back-merge latest from original author.
…cal migrations) will be removed in Django 1.9.
Back-merge + fix Django warnings for 1.9.
Add Migrations & improve 1.9 compatibility
Fix bad merge
Fix tests and update away from private _meta API usage
Update compatibility for Django 1.10
Because Django 1.10 removed model._meta.get_all_field_names, it must be implemented as a model method. These changes are backwards compatible with Django 1.8, 1.9 Refer to the docs to implement _get_all_field_names as a model method or util function. https://docs.djangoproject.com/en/1.10/ref/models/meta/#migrating-from-the-old-api
Modify to_dict for use with Django 1.10
Update version in setup so pip will find the most recent commit
Update version so pip will find the most recent commit
@leandrosouza Do you know when you'll be able to look at this? Not trying to push, just curious. Thanks for your help! :) |
I just noticed that the quoting is a bit off. Marking this as a WIP until I fix it and push. |
WTFox
changed the title
Add Support for Django 1.11 and add Python 3 support.
[WIP] Add Support for Django 1.11 and add Python 3 support.
Jan 29, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds support for Python 3 and Django 1.11.
A high level overview
django.conf.urls.patterns
since support was added for plain lists.str
. Also addspython_2_unicode_compatible
to Django models so that only__str__()
has to be implemented.dict.keys()
to a list since it's not that.del dict[some_key]
in iterations to avoid throwing a Iterable size changed during iteration error.Notes:
django.conf.urls.patterns
support was removed in 1.8, so I've updated the readme to suggest using Django >= 1.8Dangers with upgrading to Python 3
While this library works out of the box with Python 3 there is a caveat that could cause unexpected side effects. For that to happen the following conditions have to be true:
GenericRelation
tosimple_audit.Audit
from a Model that you've registered with Simple AuditLets say that a model contains a GenericRelation back to
simple_audit.Audit
so that the audits can be queried likeinstance.audits.all()
and a new row gets added to the db. Simple Audit will mark that as anADD
operation and will create a record for it. It will look for all fields on the model and get the new and existing values for each one. It works as expected for all fields until it gets to ouraudits
field, the GenericRelation.What happens is that it looks for the value and calls
unicode
on it. The value in this case is aGenericRelationObjectManager
instance, but callingstr()
on it will resolve it tosimple_audit.Audit.None
. This went largely unnoticed because the subsequent changes to the model would produce the same value foraudits
.Python 3 comes in like a wrecking ball and obviously
unicode()
is no longer available. We havestr()
now for string types. Replacing theunicode
usage withstr
does something entirely unexpected. Instead of resolving to the samesimple_audit.Audit.None
string, it now produces a string of the objects repr with memory locations e.g.'<django.contrib.contenttypes.fields.GenericRelatedObjectManager object at 0x10a72d510>'
This matters because when Simple Audit gets triggered, it gets the existing value and new instance value of all fields on the model - including fields that have a GenericRelation back to
simple_audit.Audit
. Which means there will always be a difference because of memory locations being printed in the string.Long story short, upgrading to Python 3 can and probably will add extraneous information to your audit_change table and will muddy the information making it harder to digest.