{{{
class Person(models.Model):
name = models.CharField(max_length=100, unique=True)
class Pet(models.Model):
name = models.CharField(max_length=100)
owner = models.ForeignKey(Person, models.CASCADE)
class Meta:
order_with_respect_to = "owner"
}}}
then adding some object, and declaring an order for the pets:
{{{
human = Person.objects.using("other").create(name="Human")
dog = Pet.objects.using("other").create(name="Dog", owner=human)
cat = Pet.objects.using("other").create(name="Cat", owner=human)
duck = Pet.objects.using("other").create(name="Duck", owner=human)
human.set_pet_order([duck.pk, dog.pk, cat.pk], "other")
}}}
Then simply trying to get the previous or next pet will fail:
{{{
>>> dog.get_next_in_order() # would expect `cat`
models.Pet.DoesNotExist: Pet matching query does not exist.
>>> dog.get_previous_in_order() # would expect `duck`
models.Pet.DoesNotExist: Pet matching query does not exist.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33945>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: Wael Ramadan (added)
* owner: nobody => Wael Ramadan
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:1>
* stage: Unreviewed => Accepted
Comment:
OK, I think this is valid. `Model._get_next_or_previous_in_order()`
doesn't apply `using()` at all.
[https://github.com/django/django/blob/e9fd2b572410b1236da0d3d0933014138d89f44e/django/db/models/base.py#L1170-L1191
src]
Reproduces with the following diff:
{{{
diff --git a/tests/multiple_database/models.py
b/tests/multiple_database/models.py
index 7de784e149..4c8bdffb96 100644
--- a/tests/multiple_database/models.py
+++ b/tests/multiple_database/models.py
@@ -79,3 +79,18 @@ class UserProfile(models.Model):
class Meta:
ordering = ("flavor",)
+
+
+class Question(models.Model):
+ text = models.CharField(max_length=200)
+
+
+class Answer(models.Model):
+ text = models.CharField(max_length=200)
+ question = models.ForeignKey(Question, models.CASCADE)
+
+ class Meta:
+ order_with_respect_to = "question"
+
+ def __str__(self):
+ return self.text
diff --git a/tests/multiple_database/tests.py
b/tests/multiple_database/tests.py
index 7a9ff4da4e..8bf30c6fd9 100644
--- a/tests/multiple_database/tests.py
+++ b/tests/multiple_database/tests.py
@@ -12,7 +12,7 @@ from django.db.models import signals
from django.db.utils import ConnectionRouter
from django.test import SimpleTestCase, TestCase, override_settings
-from .models import Book, Person, Pet, Review, UserProfile
+from .models import Book, Person, Pet, Review, UserProfile, Question,
Answer
from .routers import AuthRouter, TestRouter, WriteRouter
@@ -2503,6 +2503,17 @@ class RouteForWriteTestCase(TestCase):
self.assertEqual(e.model, Book)
self.assertEqual(e.hints, {"instance": auth})
+ def test_order_with_respect_to(self):
+ q = Question.objects.using("other").create(text="The question")
+ a1 = Answer.objects.using("other").create(text="Answer 1",
question=q)
+ a2 = Answer.objects.using("other").create(text="Answer 2",
question=q)
+ a3 = Answer.objects.using("other").create(text="Answer 3",
question=q)
+ q.set_answer_order([a1.pk, a2.pk, a3.pk], "other")
+
+ a2.refresh_from_db()
+ self.assertIs(a2.get_next_in_order(), a3)
+ self.assertIs(a2.get_previous_in_order(), a1)
+
class NoRelationRouter:
"""Disallow all relations."""
}}}
Let's accept to investigate.
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:2>
Comment (by Wael Ramadan):
This seems to be working correctly in Django 4.1.2
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:3>
* status: assigned => closed
* has_patch: 0 => 1
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:4>
* status: closed => new
* has_patch: 1 => 0
* resolution: fixed =>
Comment:
If that's the case, you should identify the commit that fixed the issue.
The test that Carlton wrote in comment 2 still fails on the main and
stable/4.1.x branches, so I have my doubts this is fixed.
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:5>
* status: new => closed
* resolution: => worksforme
Comment:
Using Django 4.1.1 this does actually fail. Yet when using Django 4.1.2
this works perfectly. Yet looking at the Release notes
(https://docs.djangoproject.com/en/4.1/releases/4.1.2/) there seems to be
no mention of this ticket.
This has to be investigated as to what fixed the issue!
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:6>
* status: closed => new
* resolution: worksforme =>
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:7>
Comment (by Mariusz Felisiak):
Replying to [comment:6 Wael Ramadan]:
> This has to be investigated as to what fixed the issue!
It fails for me on the `main` branch, `stable/4.1.x` branch, and with
`4.1.2` version so it's definitely not fixed.
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:8>
Comment (by Wael Ramadan):
Replying to [comment:8 Mariusz Felisiak]:
> Replying to [comment:6 Wael Ramadan]:
> > This has to be investigated as to what fixed the issue!
>
> It fails for me on the `main` branch, `stable/4.1.x` branch, and with
`4.1.2` version so it's definitely not fixed.
How is that possible that it fails on `4.1.2` what type of database are
you using?
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:9>
Comment (by Wael Ramadan):
Replying to [comment:9 Wael Ramadan]:
> Replying to [comment:8 Mariusz Felisiak]:
> > Replying to [comment:6 Wael Ramadan]:
> > > This has to be investigated as to what fixed the issue!
> >
> > It fails for me on the `main` branch, `stable/4.1.x` branch, and with
`4.1.2` version so it's definitely not fixed.
>
> How is that possible that it fails on `4.1.2` what type of database are
you using?
OK, oddly enough purged everything and started from scratch using `4.1.2`
and it does fail.
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:10>
* owner: Wael Ramadan => Aryan Amish
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33945#comment:11>