One database table, one model, many behaviours: Proxy model with Ronald Maravanyika

Thank you so much. Um Yeah, so just like the previous speaker, I came a very long way. So my name is Ron. I'm a co-founder of a nonprofit called Zimbopie. We teach young girls how to code. I'm also an individual member of The DSF, um I'm also a member of the PSF and I've been organizing Django Girls. Uh I'm a Formula One lover and a cricket fan, which is not something popular on this side of the world. Um

so I thought I came from a long way, so let me just tell you a bit about my country My country is on the southern part of Africa and we own that instrument. It's a musical instrument. It's called Mbira. Uh I'm hoping this will work, but I just want to make you hear how it sounds like. Start from the top. Okay So that's Bira for you, and it's unique to Zimbabwe. Um one of the things about Zimbabwe, we own uh

one of the seven natural wonders of the world. So feel free to visit the Vic Falls. There are a bunch of other things that you can do in Zimbabwe. We own the largest min -made lake in the world. So I thought I should share some of these. Anyway, let's get into it. So my talk will be structured in sort of two Two sections. The first section is sort of beginner and it slowly transition into intermediate. Um depending on who you are, you might think that's senior. Uh so I'll be talking about models, model inheritance, uh, which will be like the beginner section, and then

it will slowly transition into like um uh um intermediate to senior where we are talking about why proxy proxy models and uh the model manager So models are sort of the describing features of your of your of your data. So they give your your your data structure. And personally, when I came into Django, that is something that drew me closer to Django. Not only models do they come with a An API, it it is easy.

You don't have to look at the database. Um, you don't have to write queries, things like that. So defining model, uh, it's um uh that's how you would define a model, and uh the the the cage is that you just have to subclass the um The models that uh come with Django. So um In Django, it really, really tries to sort of stick to the zen of Python And one of the things that I like about the scene of Python is that

simple is better than complex, right? So not only When you write code, you're not writing code just for the machine, you're also writing code for other people. And if your code is not clear enough, that might introduce bugs into your your your project. Uh the the the other thing that I like is the fact that It really counts to write readable code. Like I said before, you're also writing the code for the human being. So you you have to keep that in mind. So

Django is tried to um inherit what Python has in terms of um inheritance and that's in um models So model inheritance, it sort of tries to fulfill that concept of simple is better than complex. You don't have to write the same code multiple times. Okay. Um so some of the things that that uh uh the advantages of um uh inheritance um These things are very important when you are writing an application, right?

And not only will that make your application sustainable, but it will make Other new people want to get into your project, especially in open source, they would get interested in your project because it's easier. So I'm gonna talk about uh uh inheritance in models. There are three types. Uh there is abstract and then there is um Multi-table inheritance and the other one is the main one that's why we are here. Right? Um so there is a case where There is an existing database. And in my examples,

I made two scoops of junk. So in some of my examples, I might include ice cream. Um I don't really like it that much, but uh it's by Danny, ask him. Um yeah, so We are going to sort of uh look at these two uh inheritance types that we have and then compare it to the proxy model and that How proxy can be very useful for you when you um uh working on an existing project that just needs new functionality. So um when you are talking about uh the abstract

base classes you are simply Trying not to repeat yourselves. So if you have uh fields that you're using in a a few other places, it's best to use um the the abstract uh base classes. Um the way you define them is quite simple. Um you define your model as normal and to declare it you just uh add in a meta class within um abstract equals to true and that will make your model abstract This means that your model doesn't have a database, um, but

you can reuse it. So to use it, that's the lower part. Um that's how you will be able to use it. Then multiple uh table inheritance. Uh this one is a bit I don't want to say complicated, but there are a few parts to it, right? Um you have tables But you don't need to add tables to more tables. So you can use the existing tables to link them to your um To your new table and the way you declare them, something like that. Uh, and there are like multiple types of uh this type of inheritance, many to many, many to one, one-to-one.

Um so something that you have to be careful when you are using this type of inheritance. This is quite good, but As for a case that you have an existing database, at times that database is already in production, people are using that database, and you want something that will just plug it. Plug it into uh the existing system. But you don't really want to create a new table, right You just want to use the database that is there and sort of just tune in the the Pythonic behavior. So um that is where uh proxy models

shine, right? They are the third layer of um inheritance. And the reason why I made this talk is because I don't think they are popular and for me it's a gem that uh helped me. So hopefully it will help someone here. Um and basically with proxy models you are not really creating a new database, you're just using Uh, what is there? We are using the table that is there, and you can sort of extend um from the existing data and we are going to take a look at um how uh that can be done.

Um to declare a proxy model Uh I'm going to use uh an example and I tried to use some of the things that we have been talking about at this conference. Um So we are going to be using a a class called Nerd, right? So the NED class is The existing database that we have, right? And in that NED class, we are going to be adding uh a few other things we are going to add a programmer we are going to add a doctor and we are going to add a a Django

nut right Um so this is the simple declaration that you do for a proxy model and You see just like the abstract one, um you call it using the your uh meta class. You just set it the proxy equals to true. And um let's if we look at the console, um you see what's happening here is We defined the NED object, right? And we created this Maranika object that has got N, right?

And you can see that in the NED object, there is only one item that is there. We did not declare any other item. But if you look at the programmer uh object, there is also one item that is there, but we did not create it directly. So it means the the programmer is using uh the NED class that already exists. Okay, so this is a very very good starting step because you now have access to your existing data that is there. Um but um You might want to have a bit more

control over that. And this is something that Django does intentionally because it wants you to have control over uh what you do So um here I'm just adding those uh few other classes that I was talking about. Um And the behavior is pretty much the same. Um we have one class and those objects we uh find them in multiple places. Uh I've used a couple of my friends' names in here. Hopefully you don't mind.

Um So yeah, yeah, it's still the same structure. But we would want a scenario if I go back, we would want a scenario where We have the existing uh database of nerds. So let's say we have a database of all uh Django con attendees and we call them nerds, right? We think that we want to sort of classify them into programmers, doctors, and Django nuts, right? So it would be good to have One callable um object for each one of them And this is

where we introduce the concept of a model manager. What a model manager is, is um It hacks the default uh model API and you are now trying to create your own query that's different from the generic object uh uh manager that comes with Django So to just to to remember, if you don't know what a manager is, you are just that's the query section of your of your model. Uh the

objects, the dot objects that you see that come with with model, that's the default manager. And in this case, we are not going to change that object name. So what you simply do is You declare your manager class, right? And it extends from the default manager model. And the get query set is uh how can I put it? It's it's similar to like your whatever your class name is dot object. or.

So that's what we have here when we say get query set. But on top of that, we want to filter just the programmer uh side of it. So you add in a filter in front of that, and you have your um manager. Uh to use your manager , you change the default objects into use your newly defined um Model manager. And uh I will talk about the method that's down there, the method called fix something. I will talk about it uh very soon. So

now let's look at what happens when we do that, when we add a model manager. You will see that in the first section there we now have uh a programmer filtered um object right but still we didn't define a a a manager for doctor So if you check what's in Dr. Doctor still has access to everything that is in the database. So what we have done here, we have just changed. Um the behavior of our model

using the same data. Okay So, um you can give your Now now we have like separate things. We now have uh programmers, we now have doctors, but we would want to give them certain attributes. That are different from each other. So you will see what I'm talking about in a minute. Um in the programmer model, we want them to have uh the ability to to be engineers and fix everything.

So you can write your your method. Here I just kept it simple to to write. I'm an engineer. I fix it all again in the context of some of the talks. At this conference. And uh you can do the same thing for your manager as well as your um Your Django nut models and you give them different attributes So now you will see that in programma you are able to call the fix something method on it, but you can't call that on the doctor method.

We are just changing the Pythonic behavior. We are still using the same table. We are still using the same database. Same applies for uh Django nuts. have a contribute um method within that. So I think it's something that is cool to be able to to do that. The last thing that I would like to showcase is the save method, hacking the save method. So you see that previously we were explicitly Uh creating types of objects, right?

So we would create the name and then add in the type of that object But we don't want to do it anymore. We want something that's that will be generic. So we hake in the default save method and If you create a new object, you no longer need to specify the NED type that you are using. You just specify the first name and the last name. and your um your proxy model will work as no more

Now, let's just take a quick look at some of the use cases that we can we can um have with uh proxy models. You can extensively extend your base user model. You might want to give different users different permissions , and that's something that you can do. With uh proxy models. Um is sometimes used to customize the Django admin. Um In a cool way, uh, I know uh Danny did a very cool tutorial around how you can uh customize your Django admin

using um proxy models. Then like the example that we mentioned now, it it's very, very useful when you are using um an existing table But you don't really want to make another table, you just want to change the pythonic behavior of it. So these are the some of the use cases that you can use um within your proxy model. So just to summarize, uh we have looked at uh Django models and the database access API, which is which I think is why people love Jungo so much.

Um we have also talked about the the the types of inheritance, abstract, multi-table, and proxy, uh abstract We said we are trying to reuse the same fields while a multi-table one, it has got like a different table, a separate table, but you just want to link the two. Proxy model, you have the same table, but you are just changing the Pythonic behavior. Um Then we also looked at uh model managers, which

I think if you Don't know about um managers, that's something that you should look at if you're a Django developer. Then lastly, um we talked about uh how you are you can just add the Pythonic behavior of your um model That is pretty much it. Uh, you can scan that QR code if you want to link with me on LinkedIn. Thank you so much.