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
update individual item for instance case #39
Conversation
fix use model or concrete model
neat. looks like the new model meta api in Django 1.8 breaks things though. I was trying to avoid a db lookup, but looking at your solution, it seems worth having for simpler code. Performance in the Django admin is kind of a joke anyways. |
I copied the |
Is the requirements.txt file relevant? It isn't getting executed by the setup, contains a hard coded version of django and other dependencies, and isn't used by tox. I think it can be included in the setup.py and tox if you'd like to keep it. It would probably have to have pretty wide ranges like |
|
@@ -1,6 +1,6 @@ | |||
Django==1.8.4 | |||
dj-database-url==0.3.0 | |||
django-extensions==1.5.5 | |||
django-extensions>=1.5.8 |
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.
I always pin exact versions in Python projects because writing I'm too lazy to write and don't like the look of django-extensions>=1.5.8,<1.6
and Python doesn't have 1.5.x
, ^1.5.8
or ~1.5.8
.
updated to pin to django-extensions==1.5.9 |
Fix how queryset-ish wasn't queryset-ish enough
The docs have
but this updates all values since queryset seems to ignore the
_result_cache
(as proven by the test in my first commit). I'm not surefilter(pk=...)
is the right way to implement this behavior, but@takes_instance_or_queryset
seems dangerous as it is now.