← Back to branch summary

~ubuntu-branches/ubuntu/quantal/python-django/quantal

« back to all changes in this revision

Viewing changes to tests/regressiontests/select_related_regress/models.py

  • Committer: Bazaar Package Importer
  • Author(s): Chris Lamb
  • Date: 2009-07-29 11:26:28 UTC
  • mfrom: (1.1.8 upstream) (4.1.5 sid)
  • Revision ID: james.westby@ubuntu.com-20090729112628-pg09ino8sz0sj21t
Tags: 1.1-1
http://bugs.debian.org/538863
* New upstream release.
* Merge from experimental:
  - Ship FastCGI initscript and /etc/default file in python-django's examples
    directory (Closes: #538863)
  - Drop "05_10539-sphinx06-compatibility.diff"; it has been applied
    upstream.
  - Bump Standards-Version to 3.8.2.

Show diffs side-by-side

added added

removed removed

Lines of Context:
tests/regressiontests/select_related_regress/models.py
 
1
from django.db import models
 
2
 
 
3
class Building(models.Model):
 
4
    name = models.CharField(max_length=10)
 
5
 
 
6
    def __unicode__(self):
 
7
        return u"Building: %s" % self.name
 
8
 
 
9
class Device(models.Model):
 
10
    building = models.ForeignKey('Building')
 
11
    name = models.CharField(max_length=10)
 
12
 
 
13
    def __unicode__(self):
 
14
        return u"device '%s' in building %s" % (self.name, self.building)
 
15
 
 
16
class Port(models.Model):
 
17
    device = models.ForeignKey('Device')
 
18
    port_number = models.CharField(max_length=10)
 
19
 
 
20
    def __unicode__(self):
 
21
        return u"%s/%s" % (self.device.name, self.port_number)
 
22
 
 
23
class Connection(models.Model):
 
24
    start = models.ForeignKey(Port, related_name='connection_start',
 
25
            unique=True)
 
26
    end = models.ForeignKey(Port, related_name='connection_end', unique=True)
 
27
 
 
28
    def __unicode__(self):
 
29
        return u"%s to %s" % (self.start, self.end)
 
30
 
 
31
# Another non-tree hierarchy that exercises code paths similar to the above
 
32
# example, but in a slightly different configuration.
 
33
class TUser(models.Model):
 
34
    name = models.CharField(max_length=200)
 
35
 
 
36
class Person(models.Model):
 
37
    user = models.ForeignKey(TUser, unique=True)
 
38
 
 
39
class Organizer(models.Model):
 
40
    person = models.ForeignKey(Person)
 
41
 
 
42
class Student(models.Model):
 
43
    person = models.ForeignKey(Person)
 
44
 
 
45
class Class(models.Model):
 
46
    org = models.ForeignKey(Organizer)
 
47
 
 
48
class Enrollment(models.Model):
 
49
    std = models.ForeignKey(Student)
 
50
    cls = models.ForeignKey(Class)
 
51
 
 
52
# Models for testing bug #8036.
 
53
class Country(models.Model):
 
54
    name = models.CharField(max_length=50)
 
55
 
 
56
class State(models.Model):
 
57
    name = models.CharField(max_length=50)
 
58
    country = models.ForeignKey(Country)
 
59
 
 
60
class ClientStatus(models.Model):
 
61
    name = models.CharField(max_length=50)
 
62
 
 
63
class Client(models.Model):
 
64
    name = models.CharField(max_length=50)
 
65
    state = models.ForeignKey(State, null=True)
 
66
    status = models.ForeignKey(ClientStatus)
 
67
 
 
68
# Some model inheritance exercises
 
69
class Parent(models.Model):
 
70
    name = models.CharField(max_length=10)
 
71
 
 
72
    def __unicode__(self):
 
73
        return self.name
 
74
 
 
75
class Child(Parent):
 
76
    value = models.IntegerField()
 
77
 
 
78
class Item(models.Model):
 
79
    name = models.CharField(max_length=10)
 
80
    child = models.ForeignKey(Child, null=True)
 
81
 
 
82
    def __unicode__(self):
 
83
        return self.name
 
84
 
 
85
__test__ = {'API_TESTS': """
 
86
Regression test for bug #7110. When using select_related(), we must query the
 
87
Device and Building tables using two different aliases (each) in order to
 
88
differentiate the start and end Connection fields. The net result is that both
 
89
the "connections = ..." queries here should give the same results without
 
90
pulling in more than the absolute minimum number of tables (history has
 
91
shown that it's easy to make a mistake in the implementation and include some
 
92
unnecessary bonus joins).
 
93
 
 
94
>>> b=Building.objects.create(name='101')
 
95
>>> dev1=Device.objects.create(name="router", building=b)
 
96
>>> dev2=Device.objects.create(name="switch", building=b)
 
97
>>> dev3=Device.objects.create(name="server", building=b)
 
98
>>> port1=Port.objects.create(port_number='4',device=dev1)
 
99
>>> port2=Port.objects.create(port_number='7',device=dev2)
 
100
>>> port3=Port.objects.create(port_number='1',device=dev3)
 
101
>>> c1=Connection.objects.create(start=port1, end=port2)
 
102
>>> c2=Connection.objects.create(start=port2, end=port3)
 
103
 
 
104
>>> connections=Connection.objects.filter(start__device__building=b, end__device__building=b).order_by('id')
 
105
>>> [(c.id, unicode(c.start), unicode(c.end)) for c in connections]
 
106
[(1, u'router/4', u'switch/7'), (2, u'switch/7', u'server/1')]
 
107
 
 
108
>>> connections=Connection.objects.filter(start__device__building=b, end__device__building=b).select_related().order_by('id')
 
109
>>> [(c.id, unicode(c.start), unicode(c.end)) for c in connections]
 
110
[(1, u'router/4', u'switch/7'), (2, u'switch/7', u'server/1')]
 
111
 
 
112
# This final query should only join seven tables (port, device and building
 
113
# twice each, plus connection once).
 
114
>>> connections.query.count_active_tables()
 
115
7
 
116
 
 
117
Regression test for bug #8106. Same sort of problem as the previous test, but
 
118
this time there are more extra tables to pull in as part of the
 
119
select_related() and some of them could potentially clash (so need to be kept
 
120
separate).
 
121
 
 
122
>>> us = TUser.objects.create(name="std")
 
123
>>> usp = Person.objects.create(user=us)
 
124
>>> uo = TUser.objects.create(name="org")
 
125
>>> uop = Person.objects.create(user=uo)
 
126
>>> s = Student.objects.create(person = usp)
 
127
>>> o = Organizer.objects.create(person = uop)
 
128
>>> c = Class.objects.create(org=o)
 
129
>>> e = Enrollment.objects.create(std=s, cls=c)
 
130
 
 
131
>>> e_related = Enrollment.objects.all().select_related()[0]
 
132
>>> e_related.std.person.user.name
 
133
u"std"
 
134
>>> e_related.cls.org.person.user.name
 
135
u"org"
 
136
 
 
137
Regression test for bug #8036: the first related model in the tests below
 
138
("state") is empty and we try to select the more remotely related
 
139
state__country. The regression here was not skipping the empty column results
 
140
for country before getting status.
 
141
 
 
142
>>> australia = Country.objects.create(name='Australia')
 
143
>>> active = ClientStatus.objects.create(name='active')
 
144
>>> client = Client.objects.create(name='client', status=active)
 
145
 
 
146
>>> client.status
 
147
<ClientStatus: ClientStatus object>
 
148
>>> Client.objects.select_related()[0].status
 
149
<ClientStatus: ClientStatus object>
 
150
>>> Client.objects.select_related('state')[0].status
 
151
<ClientStatus: ClientStatus object>
 
152
>>> Client.objects.select_related('state', 'status')[0].status
 
153
<ClientStatus: ClientStatus object>
 
154
>>> Client.objects.select_related('state__country')[0].status
 
155
<ClientStatus: ClientStatus object>
 
156
>>> Client.objects.select_related('state__country', 'status')[0].status
 
157
<ClientStatus: ClientStatus object>
 
158
>>> Client.objects.select_related('status')[0].status
 
159
<ClientStatus: ClientStatus object>
 
160
 
 
161
Exercising select_related() with multi-table model inheritance.
 
162
>>> c1 = Child.objects.create(name="child1", value=42)
 
163
>>> _ = Item.objects.create(name="item1", child=c1)
 
164
>>> _ = Item.objects.create(name="item2")
 
165
>>> Item.objects.select_related("child").order_by("name")
 
166
[<Item: item1>, <Item: item2>]
 
167
 
 
168
"""}