id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
13296	order_with_respect_to fails to correctly track _order after deleting entries	Chris	Hasan Ramezani	"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"	Bug	closed	Database layer (models, ORM)	1.1	Normal	fixed			Accepted	1	0	0	0	0	0