This repository has been archived by the owner on Feb 28, 2020. It is now read-only.
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.
While working with the REST API, I ran into a problem with the inbox-detail view.
The inbox-list view serializes all messages in a user's inbox. The "id" values in the JSON response are primary keys of Message objects (when using the DefaultBackend). The /inbox/{id}/ endpoint provides a detail view of those messages. In the process, however, the "id" (of a message) is inadvertently used as the primary key of an Inbox object:
https://github.com/evonove/django-stored-messages/blob/master/stored_messages/backends/default/backend.py#L43
Why doesn't this show up in the current tests? Message and Inbox objects are often created in pairs. If the database starts numbering both tables at 1, corresponding objects will have the same primary key. Of course, you cannot rely on this.
I created a test that demonstrates the problem. By sending the same message to two users, the primary keys of the underlying message and inbox tables are no longer synchronous. In this situation, user2 can no longer obtain a detail view if user1 marks his message as read.
While writing my test, I noticed that api functions such as "add_message_for" are not using the STORAGE_BACKEND overridden by TestRESTApiWithRedis. I fixed this as well, by doing an inline import. NB: views.py is already doing it this way, so this fix is consistent with that.