Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Django ORM: Accessing a Single Project
To get started, go into the Django shell and bring up models.py so you can have an overview of what’s in that file. First, you need to import:
>>> from projects.models import Project
Now, you can interact with it and revisit what you did to get all of the models:
>>> projects = Project.objects.all()
00:00 Let’s jump right into the Django shell.
00:04
Remember, we did that by typing python manage.py shell,
00:11
and now we’re inside of the Django shell. I’m just going to pull up here also the models file, because we’re going to deal with our models, so it’s nice to have an overview sitting up here. Cool.
00:22 First, we have to import them
00:25
and I see that projects.models, so our Project model in here, let’s go ahead and say from projects.models import Project, and now we can interact with it. What I’m going to do next, I’m going to revisit what we did to get all of the models. So we did, like we said, projects = Project…
00:53
.all(), and that’s returned to us a QuerySet that contains all of the projects that are currently in the database. Cool. What I did to get to one Project was I said, p1 is—from this selection, I can slice it and I can say, “Give me the first item,”
01:11
so now I have access to this one Project object. I can go to its .title, et cetera. But that’s not the most convenient way of doing it because how am I going to know how many projects are in there?
01:24
How am I going to access this very specific one? Slicing here is not the best way to do this. And the Django ORM has its specific function for doing just that: getting a specific Project. And the function looks like that.
01:37
If I want to get p2, for example, I’m going to say Project.objects.get(), and then I have to provide something. I have to provide an identifier.
01:51
So, we talked about that we don’t see this here, but every Django model that gets created automatically gets an id column that’s going to be the primary key of our model.
02:02
So what I can do in here is I can say id=2, so this is going to be this one here. I get access to my second Project object. Again, I can do things like that—.title—just to prove that now we’re at the second one. Cool!
02:23
So, maybe what you might see online or what we’re actually also going to use in this is not id—that’s the name of our column here—but there is something called a primary key. Instead of id, what his id column stands for is actually the primary key of our table, so what you can type instead of id is pk, and this has the same effect.
02:51
Let’s take a bit of a closer look at this. What is pk? pk stands for primary key. If you remember, when we took a look at our table that we created—the projects table—in here, we have title, description, technology, which are column names that we defined in our Django model.
03:11
Then, there’s this automatically-generated one that Django names id. id is the name of it, and in our project, the primary key, therefore, is the same as id. You could name this differently, you could choose another column to be the primary identifier, but every table needs to have a primary key.
03:30
So generally, we’re just going to use pk and in all instances when we autogenerate a Django model, this is going to correspond to id.
03:40
So keep in mind, if you see pk, it stands for the primary key and that’s our unique identifier for one object inside of our table. And that’s exactly what we’re looking for, so we want to target one row in our table and pick all that information from that row out, put it back into a Python object, and then be able to use it in our code.
03:59 That’s exactly what we’re using this for.
04:03
.objects.get—the name of our model .objects.get, and then we’re passing in a primary key. In this case, that’s an id, which is an auto-incrementing number. I’m selecting a specific one—in this case, our second Project. All right, that’s all for now. In the next video, we’re going to head over and use this newly-found knowledge of accessing one specific Project by its primary key in order to build out this page where we can just see this one specific object.
Martin Breuss RP Team on March 8, 2020
Hi @reblark! Seems I missed this comment of yours, sorry about that, and nice discovery!
What’s Happening Here?
What you’ve encountered is standard behavior for a database. The ID of an entry should uniquely identify a given entry, and there’s no reason for your database to assume that you’d want a new entry to take on the ID of an old, deleted entry. Django’s flush follows that convention.
So, to answer your question: The entries are really gone, but their IDs are now out of the game as far as your database is concerned.
How To Reset IDs
If you really want to reset the IDs, the easiest way is to delete your database file and recreate it (when using SQLite), or write some SQL code to drop the table and recreate it (when using e.g. PostgreSQL).
You can read more about all this in this StackOverflow thread and this blog post.
Wartem on Oct. 15, 2022
ORM is a fitting name since it means snake in Swedish.
“Orm (in Old Norse and in modern Danish, Swedish, Norwegian (bokmål and nynorsk) the word for “snake”, “worm” or “dragon”)”
Martin Breuss RP Team on Oct. 18, 2022
:) 🐍🪱🐉
oldmanwoerle on Feb. 28, 2023
@reblark
As Martin stated, this is standard behavior for a database. Its not that the records still exist, its that databases keep track in a separate system table the last primary key that was used. So when you dropped the data from your table, you aren’t dropping the data from the system table that records the last used Primary Key. There are many reasons why DBs do this. One is for performance. when you have millions of records, its a lot faster to grab the last PK from a system table then to search through all those records for whatever the last record is. Another reason is specifically so that you don’t reuse a primary key. This is a feature, not a bug. Primary keys are very often used to relate one piece of data in one table to data in another table. take for instance if you had one table that listed your projects header information (Name, img, description), like in this tutorial. And you have a detail table that went into more granular information about each project. If you wiped the header table and not the detail table, then started adding new projects into both your header and detail tables, then project 4’s header would point to project 1’s detail, 5 to 2, 6 to 3 and so on.
Become a Member to join the conversation.
reblark on Nov. 12, 2019
In a previous exchange with you I mentioned the possibility of using python manage.py flush to take out the entries in the database. There were three entries that I have made. I went ahead and did that so I had a db with no rows. Using the shell cl funcxtion, I added three more. The first three no longer appear, but when I use “id” or “pk”, I have to use id=4 (pk=4) and id=5 (pk=6). That tells me that the first three entries are not really gone. Where are they?