Django의 모델 정의와 각 모델 간의 일대일, 다대일, 다대다관계 및 등급 조회 문제

Field lookups¶

Field lookups are how you specify the meat of an SQLWHERE clause. They're specified as keyword arguments to theQuerySet methodsfilter(),exclude() andget().

Basic lookups keyword arguments take the form field__lookuptype=value. (That's a double-underscore). For example:

>>> Entry.objects.filter(pub_date__lte='2006-01-01')

SELECT * FROM blog_entry WHERE pub_date <= '2006-01-01';

>>> Entry.objects.filter(blog_id__exact=4)

The database API supports about two dozen lookup types; a complete reference can be found in thefield lookup reference. To give you a taste of what's available, here's some of the more common lookups you'll probably use:

exact

An "exact" match. For example:

 

>>> Entry.objects.get(headline__exact="Man bites dog")

Would generate SQL along these lines:

SELECT ... WHERE headline = 'Man bites dog';

If you don't provide a lookup type -- that is, if your keyword argument doesn't contain a double underscore -- the lookup type is assumed to beexact.

For example, the following two statements are equivalent:

 

>>> Blog.objects.get(id__exact=14)  # Explicit form
>>> Blog.objects.get(id=14)         # __exact is implied

 

This is for convenience, becauseexact lookups are the common case.

iexact

A case-insensitive match. So, the query:

 

>>> Blog.objects.get(name__iexact="beatles blog")

 

Would match a Blog titled "Beatles Blog", "beatles blog", or even "BeAtlES blOG".

contains

Case-sensitive containment test. For example:

 

Entry.objects.get(headline__contains='Lennon')

 

Roughly translates to this SQL:

SELECT ... WHERE headline LIKE '%Lennon%';

Note this will match the headline'TodayLennonhonored' but not'todaylennonhonored'.

There's also a case-insensitive version,icontains.

startswith , endswith

Starts-with and ends-with search, respectively. There are also case-insensitive versions called istartswith and iendswith .

Again, this only scratches the surface. A complete reference can be found in thefield lookup reference.

Lookups that span relationships¶

Django offers a powerful and intuitive way to "follow" relationships in lookups, taking care of the SQLJOINs for you automatically, behind the scenes. To span a relationship, just use the field name of related fields across models, separated by double underscores, until you get to the field you want.

This example retrieves all Entry objects with aBlog whosename is'BeatlesBlog':

>>> Entry.objects.filter(blog__name__exact='Beatles Blog')

It works backwards, too. To refer to a "reverse" relationship, just use the lowercase name of the model.

This example retrieves all Blog objects which have at least oneEntry whoseheadline contains'Lennon':

>>> Blog.objects.filter(entry__headline__contains='Lennon')

Blog.objects.filter(entry__authors__name='Lennon')

Blog.objects.filter(entry__authors__name__isnull=True)

Blog.objects.filter(entry__authors__isnull=False,
        entry__authors__name__isnull=True)

Blog.objects.filter(entry__headline__contains='Lennon').filter(
        entry__pub_date__year=2008)

Blog.objects.filter(entry__headline__contains='Lennon',
        entry__pub_date__year=2008)

Blog.objects.filter(entry__headline__contains='Lennon').filter(
        entry__pub_date__year=2008)

Filters can reference fields on the model¶

In the examples given so far, we have constructed filters that compare the value of a model field with a constant. But what if you want to compare the value of a model field with another field on the same model?

Django provides the F() expressions to allow such comparisons. Instances of F() act as a reference to a model field within a query. These references can then be used in query filters to compare the values of two different fields on the same model instance.

For example, to find a list of all blog entries that have had more comments than pingbacks, we construct anF() object to reference the pingback count, and use thatF() object in the query:

>>> from django.db.models import F
>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks'))

>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)

>>> Entry.objects.filter(rating__lt=F('n_comments') + F('n_pingbacks'))

>>> Entry.objects.filter(authors__name=F('blog__name'))

For date and date/time fields, you can add or subtract atimedelta object. The following would return all entries that were modified more than 3 days after they were published:

>>> from datetime import timedelta
>>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))

Caching and QuerySets¶

Each QuerySet contains a cache, to minimize database access. It's important to understand how it works, in order to write the most efficient code.

In a newly created QuerySet, the cache is empty. The first time aQuerySet is evaluated -- and, hence, a database query happens -- Django saves the query results in theQuerySet's cache and returns the results that have been explicitly requested (e.g., the next element, if theQuerySet is being iterated over). Subsequent evaluations of theQuerySet reuse the cached results.

Keep this caching behavior in mind, because it may bite you if you don't use yourQuerySets correctly. For example, the following will create twoQuerySets, evaluate them, and throw them away:

>>> print([e.headline for e in Entry.objects.all()])
>>> print([e.pub_date for e in Entry.objects.all()])

To avoid this problem, simply save the QuerySet and reuse it:

>>> queryset = Entry.objects.all()
>>> print([p.headline for p in queryset]) # Evaluate the query set.
>>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation.