order_with_respect_to fails to correctly track _order after deleting entries
|Reported by:||Chris||Owned by:||nobody|
|Component:||Database layer (models, ORM)||Version:||1.1|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||yes|
When using a model that orders itself with respect to another entry the "_order" value is not set correctly after an entry has been deleted, and isn't set correct if the Foreign key is changed to point from one 'Question' to another (Question here the class with the foreighn key as in the django docs), this can result in incorrect ordering, and duplicate "_order" values for objects with the same foreign key id
To reproduce this problem is simple, use the admin interface to add one question and three answers (related to that question) into the db. These will have _order values of 0, 1 and 2 (correct). Now delete the first answer and add a new answer using the admin interface and the _order value for this new answer will be 2, resulting in the three answers having values of 1, 2 and 2 (where the duplication is clearly bad - this should either still be 0, 1 and 2 with multiple entries having been changed to accomodate, or should be 1, 2 and 3 - preserving the order). The value assigned to _order seems simply to be the number of entries related to that Question, however more intelligence is needed here.
The same issue occurs when moving an answer from one Question to another, in that the answer's _order value is unchanged, when it should probably change dependent on the list it is getting inserted into.
class Question(models.Model): q = models.CharField(max_length=200) class Answer(models.Model): question = models.ForeignKey(Question) a = models.CharField(max_length=200) class Meta: order_with_respect_to = 'question'
As I see it there are two ways to solve this:
- when an Answer is saved to the db, it should get the first number larger than all current numbers
- or when an Answer is moved or deleted the remaining entries should be shuffled around so that there ordering is still complete
Either way, _order and the fk should probably be unique together as this would enforce it
This testing was done using the admin interface to add and remove the classes on Django 1.1.1 with MYSQL
Change History (10)
comment:3 Changed 7 years ago by
|Component:||Uncategorized → Database layer (models, ORM)|
|Triage Stage:||Unreviewed → Accepted|