本文共 39720 字,大约阅读时间需要 132 分钟。
参考官方网站:
Once you’ve created your , Django automatically gives you a database-abstraction API that lets you create, retrieve, update and delete objects. This document explains how to use this API. Refer to the for full details of all the various model lookup options.
Throughout this guide (and in the reference), we’ll refer to the following models, which comprise a Weblog application:
class Blog(models.Model): name = models.CharField(max_length=100) tagline = models.TextField() def __unicode__(self): return self.nameclass Author(models.Model): name = models.CharField(max_length=50) email = models.EmailField() def __unicode__(self): return self.nameclass Entry(models.Model): blog = models.ForeignKey(Blog) headline = models.CharField(max_length=255) body_text = models.TextField() pub_date = models.DateTimeField() mod_date = models.DateTimeField() authors = models.ManyToManyField(Author) n_comments = models.IntegerField() n_pingbacks = models.IntegerField() rating = models.IntegerField() def __unicode__(self): return self.headline
To represent database-table data in Python objects, Django uses an intuitive system: A model class represents a database table, and an instance of that class represents a particular record in the database table.
To create an object, instantiate it using keyword arguments to the model class, then call to save it to the database.
You import the model class from wherever it lives on the Python path, as you may expect. (We point this out here because previous Django versions required funky model importing.)
Assuming models live in a file mysite/blog/models.py, here's an example:
>>> from blog.models import Blog>>> b = Blog(name='Beatles Blog', tagline='All the latest Beatles news.')>>> b.save()
The method has no return value.
See also
takes a number of advanced options not described here. See the documentation for for complete details.
To create and save an object in a single step, use the method.
To save changes to an object that's already in the database, use.
Given a Blog instanceb5 that has already been saved to the database, this example changes its name and updates its record in the database:
>> b5.name = 'New name'>> b5.save()
Updating a field works exactly the same way as saving a normal field -- simply assign an object of the right type to the field in question. This example updates theblog attribute of anEntry instanceentry:
>>> from blog.models import Entry>>> entry = Entry.objects.get(pk=1)>>> cheese_blog = Blog.objects.get(name="Cheddar Talk")>>> entry.blog = cheese_blog>>> entry.save()
>>> from blog.models import Author>>> joe = Author.objects.create(name="Joe")>>> entry.authors.add(joe)
>>> john = Author.objects.create(name="John")>>> paul = Author.objects.create(name="Paul")>>> george = Author.objects.create(name="George")>>> ringo = Author.objects.create(name="Ringo")>>> entry.authors.add(john, paul, george, ringo)
To retrieve objects from your database, construct a via a on your model class.
A represents a collection of objects from your database. It can have zero, one or manyfilters -- criteria that narrow down the collection based on given parameters. In SQL terms, a equates to aSELECT statement, and a filter is a limiting clause such asWHERE orLIMIT.
You get a by using your model's. Each model has at least one, and it's calledobjects by default. Access it directly via the model class, like so:
>>> Blog.objects>>> b = Blog(name='Foo', tagline='Bar')>>> b.objectsTraceback: ...AttributeError: "Manager isn't accessible via Blog instances."
Managers are accessible only via model classes, rather than from model instances, to enforce a separation between "table-level" operations and "record-level" operations.
The is the main source ofQuerySets for a model. It acts as a "root" that describes all objects in the model's database table. For example,Blog.objects is the initial that contains allBlog objects in the database.
The simplest way to retrieve objects from a table is to get all of them. To do this, use the method on a:
>>> all_entries = Entry.objects.all()
(If Entry.objects is a, why can't we just doEntry.objects? That's becauseEntry.objects, the root, is a special case that cannot be evaluated. The method returns a thatcan be evaluated.)
The root provided by the describes all objects in the database table. Usually, though, you'll need to select only a subset of the complete set of objects.
To create such a subset, you refine the initial , adding filter conditions. The two most common ways to refine a are:
The lookup parameters (**kwargs in the above function definitions) should be in the format described in below.
For example, to get a of blog entries from the year 2006, use like so:
Entry.objects.filter(pub_date__year=2006) We don't have to add an --Entry.objects.all().filter(...). That would still work, but you only need when you want all objects from the root . Chaining filters The result of refining a is itself a, so it's possible to chain refinements together. For example: >>> Entry.objects.filter(... headline__startswith='What'... ).exclude(... pub_date__gte=datetime.now()... ).filter(... pub_date__gte=datetime(2005, 1, 1)... ) This takes the initial of all entries in the database, adds a filter, then an exclusion, then another filter. The final result is a containing all entries with a headline that starts with "What", that were published between January 1, 2005, and the current day. Filtered QuerySets are unique Each time you refine a , you get a brand-new that is in no way bound to the previous. Each refinement creates a separate and distinct that can be stored, used and reused. Example: >> q1 = Entry.objects.filter(headline__startswith="What")>> q2 = q1.exclude(pub_date__gte=datetime.now())>> q3 = q1.filter(pub_date__gte=datetime.now()) These three QuerySets are separate. The first is a base containing all entries that contain a headline starting with "What". The second is a subset of the first, with an additional criteria that excludes records whosepub_date is greater than now. The third is a subset of the first, with an additional criteria that selects only the records whosepub_date is greater than now. The initial (q1) is unaffected by the refinement process. QuerySets are lazy QuerySets are lazy -- the act of creating a doesn't involve any database activity. You can stack filters together all day long, and Django won't actually run the query until the isevaluated. Take a look at this example: >>> q = Entry.objects.filter(headline__startswith="What")>>> q = q.filter(pub_date__lte=datetime.now())>>> q = q.exclude(body_text__icontains="food")>>> print(q) Though this looks like three database hits, in fact it hits the database only once, at the last line (print(q)). In general, the results of a aren't fetched from the database until you "ask" for them. When you do, the isevaluated by accessing the database. For more details on exactly when evaluation takes place, see .
will always give you a , even if only a single object matches the query - in this case, it will be a containing a single element.
If you know there is only one object that matches your query, you can use the method on aManager which returns the object directly:
>>> one_entry = Entry.objects.get(pk=1) You can use any query expression with , just like with - again, see below. Note that there is a difference between using , and using with a slice of[0]. If there are no results that match the query, will raise aDoesNotExist exception. This exception is an attribute of the model class that the query is being performed on - so in the code above, if there is noEntry object with a primary key of 1, Django will raiseEntry.DoesNotExist. Similarly, Django will complain if more than one item matches the query. In this case, it will raiseMultipleObjectsReturned, which again is an attribute of the model class itself.
Most of the time you'll use ,, and when you need to look up objects from the database. However, that's far from all there is; see the for a complete list of all the various methods.
Use a subset of Python's array-slicing syntax to limit your to a certain number of results. This is the equivalent of SQL'sLIMIT andOFFSET clauses.
For example, this returns the first 5 objects (LIMIT5):
>>> Entry.objects.all()[:5]
>>> Entry.objects.all()[5:10] Negative indexing (i.e. Entry.objects.all()[-1]) is not supported. Generally, slicing a returns a new -- it doesn't evaluate the query. An exception is if you use the "step" parameter of Python slice syntax. For example, this would actually execute the query in order to return a list of everysecond object of the first 10: >>> Entry.objects.all()[:10:2] To retrieve a single object rather than a list (e.g.SELECTfooFROMbarLIMIT1), use a simple index instead of a slice. For example, this returns the firstEntry in the database, after ordering entries alphabetically by headline: >>> Entry.objects.order_by('headline')[0] This is roughly equivalent to: >>> Entry.objects.order_by('headline')[0:1].get() Note, however, that the first of these will raiseIndexError while the second will raiseDoesNotExist if no objects match the given criteria. See for more details.
Field lookups are how you specify the meat of an SQLWHERE clause. They're specified as keyword arguments to the methods, and.
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';
Python has the ability to define functions that accept arbitrary name-value arguments whose names and values are evaluated at runtime. For more information, see in the official Python tutorial.
>>> Entry.objects.filter(blog_id__exact=4)
The database API supports about two dozen lookup types; a complete reference can be found in the. To give you a taste of what's available, here's some of the more common lookups you'll probably use:
An "exact" match. For example:
>>> Entry.objects.get(headline__exact="Man bites dog")
SELECT ... WHERE headline = 'Man bites dog';
For example, the following two statements are equivalent:
>>> Blog.objects.get(id__exact=14) # Explicit form>>> Blog.objects.get(id=14) # __exact is implied
A case-insensitive match. So, the query:
>>> Blog.objects.get(name__iexact="beatles blog")
Case-sensitive containment test. For example:
Entry.objects.get(headline__contains='Lennon')
SELECT ... WHERE headline LIKE '%Lennon%';
There's also a case-insensitive version,.
Again, this only scratches the surface. A complete reference can be found in the.
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)
When you are filtering an object based on a or a reverse, there are two different sorts of filter you may be interested in. Consider theBlog/Entry relationship (Blog toEntry is a one-to-many relation). We might be interested in finding blogs that have an entry which has both"Lennon" in the headline and was published in 2008. Or we might want to find blogs that have an entry with"Lennon" in the headline as well as an entry that was published in 2008. Since there are multiple entries associated with a singleBlog, both of these queries are possible and make sense in some situations.
The same type of situation arises with a . For example, if anEntry has a calledtags, we might want to find entries linked to tags called"music" and"bands" or we might want an entry that contains a tag with a name of"music" and a status of"public".
To handle both of these situations, Django has a consistent way of processing
Blog.objects.filter(entry__headline__contains='Lennon').filter( entry__pub_date__year=2008)set of objects, but for multi-valued relations, they apply to any object linked to the primary model, not necessarily those objects that were selected by an earlier call.
That may sound a bit confusing, so hopefully an example will clarify. To select all blogs that contain entries with both"Lennon" in the headline and that were published in 2008 (the same entry satisfying both conditions), we would write:
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)
All of this behavior also applies to : all the conditions in a single statement apply to a single instance (if those conditions are talking about the same multi-valued relation). Conditions in subsequent or calls that refer to the same relation may end up filtering on different linked objects.
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 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 a 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))
For convenience, Django provides a pk lookup shortcut, which stands for "primary key".
In the example Blog model, the primary key is theid field, so these three statements are equivalent:
>>> Blog.objects.get(id__exact=14) # Explicit form>>> Blog.objects.get(id=14) # __exact is implied>>> Blog.objects.get(pk=14) # pk implies id__exact
# Get blogs entries with id 1, 4 and 7>>> Blog.objects.filter(pk__in=[1,4,7])# Get all blog entries with id > 14>>> Blog.objects.filter(pk__gt=14)
>>> Entry.objects.filter(blog__id__exact=3) # Explicit form>>> Entry.objects.filter(blog__id=3) # __exact is implied>>> Entry.objects.filter(blog__pk=3) # __pk implies __id__exact
The field lookups that equate to LIKE SQL statements (iexact,contains,icontains,startswith,istartswith,endswith andiendswith) will automatically escape the two special characters used inLIKE statements -- the percent sign and the underscore. (In aLIKE statement, the percent sign signifies a multiple-character wildcard and the underscore signifies a single-character wildcard.)
This means things should work intuitively, so the abstraction doesn't leak. For example, to retrieve all the entries that contain a percent sign, just use the percent sign as any other character:
>>> Entry.objects.filter(headline__contains='%')
SELECT ... WHERE headline LIKE '%\%%';
Each 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 , the cache is empty. The first time a is evaluated -- and, hence, a database query happens -- Django saves the query results in the's cache and returns the results that have been explicitly requested (e.g., the next element, if the is being iterated over). Subsequent evaluations of the reuse the cached results.
Keep this caching behavior in mind, because it may bite you if you don't use yours correctly. For example, the following will create twos, 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 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.
Keyword argument queries -- in , etc. -- are "AND"ed together. If you need to execute more complex queries (for example, queries withOR statements), you can useQ objects.
A Q object (django.db.models.Q) is an object used to encapsulate a collection of keyword arguments. These keyword arguments are specified as in "Field lookups" above.
For example, this Q object encapsulates a singleLIKE query:
from django.db.models import QQ(question__startswith='What')
For example, this statement yields a single Q object that represents the "OR" of two"question__startswith" queries:
Q(question__startswith='Who') | Q(question__startswith='What')
WHERE question LIKE 'Who%' OR question LIKE 'What%'
Q(question__startswith='Who') | ~Q(pub_date__year=2005)
Each lookup function that takes keyword-arguments (e.g.,,) can also be passed one or moreQ objects as positional (not-named) arguments. If you provide multipleQ object arguments to a lookup function, the arguments will be "AND"ed together. For example:
Poll.objects.get( Q(question__startswith='Who'), Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)))
SELECT * from polls WHERE question LIKE 'Who%' AND (pub_date = '2005-05-02' OR pub_date = '2005-05-06')
Poll.objects.get( Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)), question__startswith='Who')
# INVALID QUERYPoll.objects.get( question__startswith='Who', Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)))
See also
The in the Django unit tests show some possible uses of Q.
To compare two model instances, just use the standard Python comparison operator, the double equals sign:==. Behind the scenes, that compares the primary key values of two models.
Using the Entry example above, the following two statements are equivalent:
>>> some_entry == other_entry>>> some_entry.id == other_entry.id
>>> some_obj == other_obj>>> some_obj.name == other_obj.name
The delete method, conveniently, is named . This method immediately deletes the object and has no return value. Example:
e.delete()
For example, this deletes all Entry objects with apub_date year of 2005:
Entry.objects.filter(pub_date__year=2005).delete()
When Django deletes an object, by default it emulates the behavior of the SQL constraintONDELETECASCADE -- in other words, any objects which had foreign keys pointing at the object to be deleted will be deleted along with it. For example:
b = Blog.objects.get(pk=1)# This will delete the Blog and all of its Entry objects.b.delete()
Note that is the only method that is not exposed on a itself. This is a safety mechanism to prevent you from accidentally requestingEntry.objects.delete(), and deletingall the entries. If youdo want to delete all the objects, then you have to explicitly request a complete query set:
Entry.objects.all().delete()
Although there is no built-in method for copying model instances, it is possible to easily create new instance with all fields' values copied. In the simplest case, you can just setpk toNone. Using our blog example:
blog = Blog(name='My blog', tagline='Blogging is easy')blog.save() # post.pk == 1blog.pk = Noneblog.save() # post.pk == 2
class ThemeBlog(Blog): theme = models.CharField(max_length=200)django_blog = ThemeBlog(name='Django', tagline='Django is easy', theme = 'python')django_blog.save() # django_blog.pk == 3
django_blog.pk = Nonedjango_blog.id = Nonedjango_blog.save() # django_blog.pk == 4
entry = Entry.objects.all()[0] # some previous entryold_authors = entry.authors.all()entry.pk = Noneentry.save()entry.authors = old_authors # saves new many2many relations
Sometimes you want to set a field to a particular value for all the objects in a. You can do this with the method. For example:
# Update all the headlines with pub_date in 2007.Entry.objects.filter(pub_date__year=2007).update(headline='Everything is the same')
>>> b = Blog.objects.get(pk=1)# Change every Entry so that it belongs to this Blog.>>> Entry.objects.all().update(blog=b)
>>> b = Blog.objects.get(pk=1)# Update all the headlines belonging to this Blog.>>> Entry.objects.select_related().filter(blog=b).update(headline='Everything is the same')
for item in my_queryset: item.save()
>>> Entry.objects.all().update(n_pingbacks=F('n_pingbacks') + 1)
# THIS WILL RAISE A FieldError>>> Entry.objects.update(headline=F('blog__name'))
If you find yourself needing to write an SQL query that is too complex for Django's database-mapper to handle, you can fall back on writing SQL by hand. Django has a couple of options for writing raw SQL queries; see.
Finally, it's important to note that the Django database layer is merely an interface to your database. You can access your database via other tools, programming languages or database frameworks; there's nothing Django-specific about your database.
转载地址:http://qzxci.baihongyu.com/