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
Model instances without primary key value are unhashable in admin panel #678
Comments
This is weird. Ordinarily, a model without a pk should not end up there.
Do any of the "follow" relations on your model ever return an unsaved model?
…On 15 November 2017 at 11:27, Kostas ***@***.***> wrote:
I have implemented a "backup" functionality when a user wants to keep a
revision of his object along with all the related ones. I have implemented
the admin integration and registered all the "follows" correctly. When the
user presses the "create new backup" button, then the following code is
executed:
with reversion.create_revision():
main_object.save()
reversion.set_user(request.user)
reversion.set_comment(comment)
and a revision is created for the object and all the related ones.
The problem appears when I create a new object that has a relationship to
the main_object. When the new object is created, if the user presses
"Create new Backup", then a revision is successfully created for the
main_object and all the related ones BUT the previous revisions show this
message on the admin panel: "Model instances without primary key value
are unhashable".
The traceback that appears is:
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
132. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/views/decorators/cache.py" in _wrapped_view_func
57. response = view_func(request, *args, **kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/contrib/admin/sites.py" in inner
233. return view(request, *args, **kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/reversion/admin.py" in revision_view
238. context,
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/reversion/admin.py" in _reversion_revisionform_view
184. version.revision.revert(delete=True)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/reversion/models.py" in revert
89. if item not in old_revision:
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/db/models/base.py" in __hash__
521. raise TypeError("Model instances without primary key value are unhashable")
with an Exception Type of TypeError and an Exception Value of Model
instances without primary key value are unhashable
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#678>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAJFCH_KahXctYwowwA4l1Uf0LHUm2Dxks5s2sqXgaJpZM4Qex_Y>
.
|
Hmm.. can you please give me some directions on how I can check that? |
When you register your model with reversion, you are providing a "follow"
argument.
For each model that has a "follow" argument, does that "follow" list a
property on that model which might contain a related model with a primary
key of None?
For example:
class ReallyBadIdea:
@Property
def so_bad(self):
return User()
reversion.register(ReallyBadIdea, follow=["so_bad"])
In this case, when reversion, follows the ReallyBadIdeam class, it will end
up tracking a User instance with no primary key.
On the other hand, specifying the name of a built-in models.ForeignKey()
field will never have a model with a primary key of None.
…On 16 November 2017 at 09:46, Kostas ***@***.***> wrote:
Hmm.. can you give me some directions on how I can check that?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJFCAEDsz4Npr1NfGAZXQAR2ACDkU8Gks5s3ARogaJpZM4Qex_Y>
.
|
No I don't have any "follow" relations to properties, only to foreign keys. Also I checked the database entries, none of the registered fields have null pk. Something that I noticed in the traceback is that the error is thrown when the 'revert' function is called. Isn't this suspicious since the only thing I do is to visit the revision page of an object in the admin? Why is the revert function called? |
Something else I noticed: the error is produced when I create objects of 2 specific classes, that are inherited by a 3rd one, hence multi-table inheritance. When I create an object of one of those 2 classes, in the database I can find 2 revision entries of the same object (one for the child object and one for the parent object). They share the same object_id though. Is it supposed to be done this way? If not, I might have messed up the "follow" registration of those classes... |
Can you give me a minimal Python example of the inheritance structure
you're describing, and the register() calls you're making?
…On 17 November 2017 at 08:51, Kostas ***@***.***> wrote:
Something else I noticed: the error is produced when I create objects of 2
specific classes, that are inherited by a 3rd one, hence multi-table
inheritance.
When I create an object of one of those 2 classes, in the database I can
find 2 revision entries of the same object (one for the child object and
one for the parent object). Is it supposed to be done this way? If not, I
might have messed up the "follow" registration of those classes...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJFCIfORXLjIpL5TO1AmoAXiys0giK0ks5s3UkJgaJpZM4Qex_Y>
.
|
So the general structure goes like this:
Then I register using admin integration so in admin.py the structure is:
|
Same problem for me. Multi-table inheritance.
|
@platico , @roman-karpovich - thanks for the extremely useful debugging information. Can you add a debugging line to your django-reversion installation? In models.py, line 88: print(item) I want to see what relation is causing the breakage. I have my suspicions, but it would be good to confirm. Once I have that, issuing a fix should be easy. |
Django is trying to delete inherited child while parent is already deleted. |
Thanks for all the debugging help! I've uploaded a fix to master. Please let me know if it's fixed. |
Problem still persists. Objects drops their pks during .delete() call, so i think we should sync object from db, for example using |
Can I have the new stack trace?
…On 20 November 2017 at 08:09, Roman Karpovich ***@***.***> wrote:
Problem still persists. Objects drops their pks during .delete() call, so
i think we should sync object from db, for example using
item.refresh_from_db() with except on DoesNotExist. On the other hand,
this will produce huge amount of database queries...
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJFCPjExMfvSnOie2pkL3ByYcHpM2QLks5s4TPEgaJpZM4Qex_Y>
.
|
|
How annoying! I've pushed another potential fix, using the Django Collector() API which should hopefully trace all the relations correctly before deleting them. Unfortunately, this is hard for me to debug locally, as it depends on the ordering of the version models! |
@etianen seems that fix working. thanks alot. |
Cool, I'll aim for a release sometime next week! Thanks for your help!
…On 20 November 2017 at 09:13, Roman Karpovich ***@***.***> wrote:
@etianen <https://github.com/etianen> seems that fix working. thanks alot.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJFCLmdzNCgsJHFCEthXXt8YJtQixcXks5s4ULSgaJpZM4Qex_Y>
.
|
I confirm it is fixed for me too. Thank you for the help! |
I have implemented a "backup" functionality when a user wants to keep a revision of his object along with all the related ones. I have implemented the admin integration and registered all the "follows" correctly. When the user presses the "create new backup" button, then the following code is executed:
and a revision is created for the object and all the related ones.
The problem appears when I create a new object that has a relationship to the
main_object
. When the new object is created, if the user presses "Create new Backup", then a revision is successfully created for the main_object and all the related ones BUT the previous revisions show this message on the admin panel:"Model instances without primary key value are unhashable".
The traceback that appears is:
with an Exception Type of TypeError and an Exception Value of
Model instances without primary key value are unhashable
The text was updated successfully, but these errors were encountered: