ORMs and ERDs, OMG!

I'm going to be talking about object relational mappers and entity relationship diagrams and uh the kind of parallels between the two. So um I want this to be accessible to kind of beginners. So, I'll try to go through all the acronyms in just a second, but um just so I can kind of read the room, um how many people have used SQL in the last year or so? Okay, so I probably don't need to explain too much. And how many people have used Django? Okay. And um within Django, the OM I guess a little bit. Okay, good. So, I'll uh try to skip over some of the like basic details, but um otherwise I'll try to go through everything carefully. So, um because I teach databases, so I try to teach to people who don't um know anything about databases and um so I teach in St. Paul, Minnesota, but I've been coming to scale since I was a student. And um I like to use open source tools but I use Oracle at work and um so I wanted to try out open source tools in particular DBver they're a supporter of scale and I saw parallels between forward and reverse engineering features in entity relationship diagrams erds and Django's object relational mapper or ORM. So I'll define these terms, but it seems like most people have heard of these at least. So entity relationship diagrams or erds are diagrams that visualize a database's structure. The nodes represent tables aka entities. And so this is an example that we'll go through. So we have a presenter table and it's um we also have a presentation table. So this is kind of like a model of scale talks. So not every presentation has multiple speakers but if you wanted to have multiple speakers potentially and I think there are some uh you would have to have a many to many mapping between presentations and presenters. And to do that you have this many to many mapping table that has multiple different names like a join table, bridge table, intersection table, association table etc. And so uh this is modeling that many to many mapping. So the um basically um entity relationship diagrams are kind of more on the database side and object relational mappers are a little bit more on the programming side. Um so if you're more on the programming side, tables in databases roughly correspond to classes in programming languages and the rows correspond to instances. And then the edges represent relationships between the tables. So these edges here uh mean that the way that we would read this is the presenter has uh one row in the presenter table has many rows in this presentation_presenter table. And I don't know if you can see that on the the screen, but it's a kind of looks like a it's called a crow's foot. It looks like a crow's foot. That means that uh one row here corresponds to potentially many rows here. So a presenter can be registered for many presentations. And uh every row here though would correspond to just one presenter and one presentation. And so this is a foreign key. These two columns here are foreign keys that refer to the other two tables. And the edges, arrow head and tail shapes represent the cardality patterns. Uh so one to one, one to many and many to many. And here you don't see any direct many to many mapping because in debaver you can't directly represent a many to many mapping. And so if you're trying out DBver for the first time, you might get kind of um stumped by looking for the particular edge shape that is for many to many mapping because it isn't there. And I'll go over why that is. Uh but basically the different er diagramming tools show different levels of abstraction and dbvers is closer to the actual database rather than a kind of abstract data definition or data model and er diagrams are more than just visualization tools and that's kind of the point of this talk. So there's two main operations forward engineering and reverse engineering where you can generate SQL code from an ER diagram or you can create an ER diagram from SQL code or the actual database. Okay, so here's just a kind of schematic. Forward engineering goes from an ER diagram to the database schema and reverse engineering like the name suggests goes reverse. And now to get on to object relational mappers. Um so an OM is a software library that helps to store and retrieve aka map programming language objects to and from relational database. and OMS often hide the details of SQL from programmers and that can be kind of good but um it does help to know the details of SQL to see the bigger picture. So in a programming language, objects can have all sorts of data in them, but relational databases like to have data that in tables that is dedicated to just one specific type of information. And this is what's called normalization. And so there's this difference in behavior between the programming language and the database. And this is called object relational impedance mismatch. just a kind of fancy name that uh they're not a kind of onetoone mapping from the programming language to the database. So I'll be using Django as an example for the object relational mapper and Django's object relational mapper also has a two-way transformation process. So it can take programming language code class definitions and generate SQL table definitions from that. And this is called migration. And there's a couple commands actually that we'll go through. And then the so that corresponds to forward engineering. And then what corresponds to reverse engineering is where you take database code and generate Python class definitions from that. And that this is a um command line argument called inspect DB. Okay. So here is the schema for uh migrate and inspect DB. So you can see it's pretty similar to the forward and reverse engineering. I'll go over these more, but um these are just some examples that you may have heard of. It sounds like most people have heard of Django, but there's other OMS and there's other erds if you were in the talk before here before this one. Um there's other tools like mermaid that can also generate entity relationship diagrams. So these any relationship diagrams and object relational mapper features have different names. So one of the things that I wanted to do is to present them together because I think it's kind of interesting just uh in case you didn't register it before. This is the similarity of both processes. The only thing that's different is we're to going to and from an ER diagram uh with the forward and reverse engineering and we're going to and from a models py file in the case of the object relational mapper. So I kind of wish that I had realized this earlier. So hopefully it'll help others and it also helps to understand other tools like UML unified markup language or modeling language and pi reverse. So pi reverse is a pretty useful tool that if we have time I will uh present that. So I want to describe and compare and contrast forward and reverse engineering in DBver to Django's migration and inspect DB commands and compare and contrast ER diagramming tools and give a tutorial example with DBver and Django and show parallel techniques from this uh PI reverse tool and uh two-way communication is ideal. So um please ask questions or if you want to share anything please feel comfortable. So while I'm on the slide, does anyone have any questions? Keep going. Okay, so first forward and reverse engineering. I think I'll go over this uh quickly. So I think everyone knows SQL. Uh we can divide SQL into different parts. The two parts that are salient here are data definition language and data manipulation language. And the data definition language is where we create table structure. And that's going to be primarily where both of these tools work at. Um, but Django's object relational mapper also does migration of data, not just the database design. Okay. Um, so there's different levels of abstraction in ER diagrams. And if you want to compare the different tools, you kind of need to have reference to these different levels of abstraction. So at the most abstract level, you just have entities and relationships. And this is just something that I made. It isn't any one particular tool. But here you can see a many to many mapping directly between uh this example is institute and students. So maybe this is like a college or school name and then this is the student. So the way that we would read this is one student has can have many institutes that they're affiliated with but they need to have at least one. And so that's kind of like there's no free range students. And then the institute can have many students but an institute may have zero students. So maybe the institute is just a research institute and there's no students. Okay. Okay, so that's the most abstract level. Then we can go a little bit more detail and add the columns and then go into a little bit more detail and add these join tables. So there's a lot of different names for these like join, bridge, um, junction tables, associative entities. Um so this is still a many to many mapping between student and institute but it has this third table implementing the many to many mapping. Okay. Um and so some tools will require you to make this third table and other tools will do it for you automatically. And um debaver is in the latter case where we'll have to make this manually. But in Django we'll see that this third table will be created automatically. [snorts] Okay. And I went through the forward engineering and reverse engineering already. And um so you can think of forward engineering as exporting the ER diagram to a database schema and reverse engineering as importing the database schema into an ER diagram. Question. >> Okay. >> Yep. I'll repeat the question. Thanks. Uh yep. So uh the question was how do userdefined functions fit in here? So some tools will not only generate the create table statements but also things like surrogate keys and um triggers and they may also um create userdefined functions too. But I'm not 100% sure about those. But I know triggers are something that these will sometimes generate for you. So that uh saves a lot of work. Um I don't see that in debaver. So that one it seems like you have to do that manually. Questioning on that is that is there >> yeah in the visualization sometimes there's uh different symbols. Um so these are kind of the standard symbols but uh for example one that I've seen in Oracle data modeler is uh no transferability. So you can kind of think of these relationship as a a um a child and a parent relationship. And so no transferability means that you can't basically adopt a child or kind of transfer their parents. And so there is another symbol for that and that's implemented as like a trigger that will uh run before you update the foreign key of the child table. And so that is pretty handy that that you can do that so you don't have to worry about the logic of the triggers. >> Yeah. No, it would be uh represented in the symbols. >> Yep. And I don't have an example of that, but um yeah, that it would be a different symbol. And so actually these are kind of the standard symbols and there are some other symbols too like for cascading deletes. Sometimes they'll have a different symbol for that. Good questions. Any other questions? So that um is one of the things that's nice about some of the tools that it does have um these other kind of uh constraints. Okay. So this is a kind of historical um ER diagram that it um ER diagrams have been around since the 70s, so before I was born. And uh they don't look like this anymore. Um so this was before they had the crows foot style diagram. And this is a um case where you have the many to many mapping directly um displayed. So this is PG modeler. And uh here's the one that we saw again. And so here are some of the um synonyms for this third table. intersection table, association table, bridge table, junction table, join table. It's kind of a pain that there's all these terms. Does anyone have a favorite term for this? >> Lookup table. Okay, I didn't put that. Pivot table. So, it's a pain teaching to uh new students. But I like to tell the students that um whenever you have this phenomena where there's a lot of words for the same thing, it's kind of a a display of the importance of the thing. So a lot of people have took it upon themselves to name it. Okay. So DBver is the one that I'm going to be showing and that um is a supporter of scale. It supports a lot of different databases. Um it's kind of like a premium model or that the there's a paid version that includes Ford engineering but the community one does not. Um and um it's more databasecentric as opposed to modeling centric. So it doesn't include these many to many mappings. Um my SQL workbench I believe it's uh I'm not expert at this but I believe it's similar to debaver that you'll have to make these uh lookup tables, pivot tables, intersection tables. Um, PG modeler is more modeling centric. Um, another thing that you can kind of tell what is modeling centric and what is kind of more databasecentric is whether the ER diagram software is bundled with the same IDE for writing SQL. And so PG Modeler and Oracle data modeler are standalone tools for ER diagrams. They don't allow you to run SQL code in those tools. And these are kind of like uh mirror images. So this one is open source but it's not free. And this one is free but not open source. And um this one you can if you can compile it, it's free. And um if you kind of vibe compile it, it might take an hour or so. Uh and then schema spy is just reverse engineering. Irwin, I'm not too familiar with that, but it's not free or open source. And then there's DB schema, which is um a software as a service. And then the presentation before this uh mentioned uh mermaid. And so that's a kind of more general markup language that you can use to generate all different kinds of um diagrams. So some pros and cons. The ER diagrams are visual. to have a guey. You can manage different levels of detail. Ideally, um sometimes they're kind of a specific level of abstraction. It's easier for beginners. Um it may or may not be integrated with the database IDE and it keeps relational database theory as opposed to object-oriented design. And the cons are that the tools are often specific to databases. And there's not always the both forward and reverse features, forward and reverse engineering features. Sometimes they're only available in enterprise editions. And they're not designed to be integrated into applications. They're not like libraries. They're just tools. And I put this as both a pro and a con because sometimes it's nice to have everything in one tool, but sometimes it's also nice to just have um one tool for each purpose. Okay, so now moving on to Django. Django is a Python server side web framework. uh usually the kind of focus is the web server of course but the OM is very powerful and we'll be considering that part not really looking at the web part uh the component deals with mapping objects that are defined in Python to the relational database here's some other object relational mappers um does anyone have any um hot takes on comparisons between these Yep. I've had um I've had a lot more uh flex um flex flexibility using uh uh or sorry expressivity using Django's RM than just straight up SQ Alchemy. >> Okay. >> Yeah. I I found I found I found just it just it's more expressive because it's more declarative in that way. >> Yep. Yeah. Go ahead. >> Uh, my hot take is that I honestly decided not to use them. >> Okay. So, just straight SQL. >> Yeah. Admittedly, this was because I decided to do a project to I decided to not use it for my main project in order to learn SQL. >> Okay. >> And I also just like SQL. >> Okay. But do you have something to do the sanitization of the user inputs? Yeah, the Python the Python default library can sanitize. >> Okay, good. Um over there. >> Uh I've used quite a bit of the entity framework and the like um having the ability to do like select where all that kind of stuff in code um is really really nice. It's very easy to show people how it's going to >> Is that that L link or LQ? >> LQ. Yeah, link. >> Okay, >> thanks. Just getting started on started with both of them. I um started using Tortoise which is uh being sold as hey it does deals well with uh async Python async.io know uh the training materials were unusable and so I decided okay I'll try and fall back to SQL alchemy uh it at least has a lot of training materials it's not all great but at least it's there >> okay good thanks I didn't consider that but uh good to know and put that on the list for the future question >> yeah I hate to bring PHP into the mix but Laravel has a really good and like a really good query builder and OM and it makes PHP intolerable. >> Okay. [laughter] Okay. Good. Good to know. So, Laravel is also another option. Okay. And so, like I said, the migrations are roughly equivalent to forward engineering, but they have version information and they also move data. And then the inspect DV is when we want to have an existing database and uh we're managing ourself not uh managing it with Django and um this is roughly equivalent to reverse engineering. Okay. So Django has really good cross database support. Uh in the demo I'm going to kind of go um between Postgress and um SQL light and it's used as a library. There's command line scripting support and you can do more than just forward and reverse engineering. Like I said, you can store the migrations both in the database and in version control. And uh it's not as beginner friendly as er diagrams. There's no guey. It's not integrated in the sh that there's um not IDE support. Um there may be some but uh it's not like kind of um Django IDE and also it prioritizes object-oriented design over strict relational database design. And this is what's called a leaky abstraction. It's kind of what leaks through this um uh object relational impedance mismatch. Okay. So now I'll go over a demo of how to um well first I'm going to go over forward engineering. So we're going to go to DBver and convert the entity relationship diagram to Postgress. Then we're going to go to Django and show the corresponding kind of forward engineering equivalent where we're going to write some Python code and generate create table statements. Yep. would design the database schema if they were just using SQL. I'll try to point that out later. Thanks. Okay. Um and then the third part we're going to do reverse engineering. So, we're going to go back to um oh wait, we're going to look at the tables that were created by Django and then we will um see them in debaver and then we'll look at the the tables that were created by debaver and show the automatically generated Python code from that. And so this is kind of the general flow that we're going to do. We're going to create an ER diagram, then do forward engineering to Postgress. Then we'll create this models. py file do migration which is kind of aka forward engineering to SQL light which is the default database for Django when you are just doing development. Then we'll do reverse engineering. We'll see that Django has a lot more tables that are created by default. And it also has um this uh intersection table join table that's created automatically. Then finally we'll go from the the code that was the SQL code that was generated from debaver and then we will generate Python classes that can be imported into Django. Okay. So first we will convert the ER diagram to SQL create table statements. And so this is kind of the flow that I'm going to do. And I'll switch over to debaver. So debaver has this uh so I already have the diagram kind of pulled up. Let me close that. So you'll kind of get the taste of um creating a diagram from scratch. So you go to the connection that you want to create a diagram for. So the diagram doesn't live independently from the connection. And that's kind of why I called this database centric rather than modeling centric. Um sorry well you won't have to read that. Um so um what you do is you go to the connection. This allows you to browse the connections. And um I have this empty public schema. And I think in pretty much anywhere if you click here and go to I guess you have to go uh one step down. Actually if you go to like public or postgress here and then go to oh no I guess you have to go to the public and then go to view diagram. So, it's a little bit tricky to kind of figure out where to create the diagram uh at first. That's the kind of benefit of having a dedicated tool that you open it up and you're in a diagram. But, uh here you have to poke around a little bit. So, we'll go to view diagram and it'll be empty of course because there's nothing here. And what we'll do is we'll just rightclick and then go to create new table. And we'll call one table presenter. Oops. presenter and then in here. So, I made the font bigger so you could see, but now it's kind of a little bit um [snorts] uh the font is now or the columns are overlapping but um so what you do is oh start in the columns. So uh even though we'll create the index first um you can create the index in the columns heading uh so we'll go create new column and the first column we'll say is ID and so this is a little bit small this is uh data type serial not like the kind you eat for breakfast but um like a incremental ID and um we'll say that it's not null and we'll will uh set it to be unique column and the um it's going to be a primary key. So that already creates the primary key. So other tools may automatically create the primary key for you. Um this one is a little bit like I said more closer to the underlying SQL. So you have to create the ids manually. And then I'll create a column called name, like the presenter's name. And I'll make this uh text. And I'll say that it's not null. I'll say okay. And then I'll do the same for email. I'll make this uh text data type and not null. Okay. So now we have this uh entity the columns defined and um we'll go to save and that will generate the SQL for us. So this is pretty nice that it will generate the SQL for us. Uh if you're learning databases this can kind of help you to learn the create table statements by seeing kind of the picture getting converted to SQL. So we'll say execute and then now if we go to diagram here we'll see this in the diagram. Uh this is one of the kind of wonky things that if you try to create a table here it will give you a different like the look is a little bit different than the um dialogue earlier. So it just goes directly into the columns. So, I'm going to close this and go back to this public uh schema and go to refresh. So, now I'll see the table that I just created. And then in this public schemas er diagram, I will create another table. And here you can see that it looks the same. The dialogue is the same. So, I'm not really sure why there's this difference there, but uh so we'll call this presentation. And like we did before, we'll create a column for the ID type serial. Oops. Go back into this and make it not null. And Okay. So, I didn't check the index uh button when I was setting that up. And so, I think if I go to this new index from selection, it will make that into an index. And then we'll add another column for the title of the presentation. And we'll make that text. And just to kind of in the um I'll make that not null. Um for the sake of time, I'm going to skip the room number or the room and I'll just go add a um starts at for the time that the talk starts at. And we'll make this a time with time zone or time stamp with time zone. Okay. And I would probably also want to have an endzat um too, but I'm just trying to make the demo not go over time. And I'll also check that to make it um not null required. Okay. So then I'll save this and um you can see that it was a little bit different. the index now is uh created as a alter statement. It wasn't in the um the create table statement. So I'll execute that. And again I'm going to close this window and go to refresh from this window. And now I need to make the intersection table aka join table aka lookup table aka what did you say was the other name? >> Pivot table. Yeah. Okay. So, I'll go create table and we'll call this presentation_presenter. And we will um go directly to foreign keys here. And so we'll add a new foreign key. And the first one will be pointing to the presentation. And so this is a little bit uh hopefully you can see when you you want to specify which column the presentation. Oh no unique keys in table presentation. >> What's that? Um well the presenter and presentation we created and it has there's nothing in it but there should be the primary key let me >> um maybe it wasn't let me go back in here. And uh Oh, unique. Okay. Uh, >> this one. >> This one. >> Primary. Yeah, for some reason it's not letting me click on this. That seems like it would be the right way to do it. Um, let's see. I'm just going to Sometimes the best thing is just to delete and start over. Let me Let me try one more time and see if this So, there's the index. It's not letting me check the Sure. Let me um I think it's probably easier if I So, I'll go back here to the tables and uh I'm just going to delete it and say yes and then try again. So, sorry about that. So I'm going to create a column and make sure that this ID column is serial again. And I'm going to make sure that it's a unique primary key. And uh just to save time, I'm going to not put the other columns uh so we don't run out of time. And then I will do save and execute. Going to close this. Close. Oh, actually let me No, >> yeah, I was in the pro in the um process of that few diagram. Okay, I think this was the new table that um was generated. I'll just uh remove that and start from fresh. So, uh presenter. So you can kind of see that um there is some things that are um if you're familiar with SQL, it might be easier just to kind of create the tables with SQL because you're kind of fighting the um the interface presentation presenter. And so we'll go to the foreign keys, create a new foreign key. In the presenter, we'll go to this column and uh select that we want to create a new column. And we need to go to column options and change the name to presentation ID. And similarly I'll say okay we'll do the same thing for the presenter create a new column. Hation. >> I did it for presentation. >> Let me just go cancel. So there's unless I named this wrong. Let's see. Create foreign key presentation. Let's go through this one more time and see new. Okay. And we'll call that presenter ID. and say okay and okay and now we'll go to save this. Oh also uh we want to put an index so that uh those two columns together are unique. And so this is one of the things that [snorts] I'm not sure if Django does this but it it will do it in a different way that it'll create its own kind of surrogate key. So increasing index. Um, so here we'll create a new index here. And I'll I'll make this a unique index and select both of these for the unique index. And now I should be able to save this. And you can see the well that'll be small, but it's a create table statement for this third table. And so now we'll go to execute and we'll close this. And if we refresh this now we should be able to see this intersection table aka join table aka linking table aka pivot table. Okay. So that is the kind of first step that I want to do. Now let's go back here. So now I want to do the Django example. So we'll do the same example in Django. How am I doing for time? 15 minutes. Um so this is this part here. And so this is the general thing. We'll install Django into a virtual environment. Create a project called scale and then an app called talks. So the way that Django organizes this is you have a project and then you have different apps inside the project. And so you could imagine scale has a lot of different apps. One of them is talks. Maybe another one would be uh the expo hall and maybe another one for sponsors. Okay. And then uh we have to register this new app and then we can make the migrations. Okay. So first step is to make a virtual environment. So I'll use UV VN scale. I'll do VN scale. And then I will activate it. Then I'll do pip install. Oh, UV pip install. I'm new to UV, but it's pretty great. Um, UV pip install Django. What's that? And so now we have Django. And we'll use the tool Django admin. Oops. Dingo-ashadmin to start a project called scale 23. [snorts] So then we'll cd into scale 23. And if we view the directories here, we'll see that we have this manage. py file that's kind of like doing the same thing as the admin Django admin but it has the settings. So these are the settings of the project. So now I'll create an app with the manage.py script. So start app and this is talks. And so now we have this talks directory. You can see that there's a migrations directory that's empty right now before we have any migrations. And we also have this models py file. That's where we're going to put in our models. So I'm going to open the models. py oops talks. So each app will have this models. py file. And so right now it's empty. And what we'll do is we'll add these two classes class presenter models dot. So it's inheriting from this models.mmodel class. And uh we'll create we don't need to create an ID because Django will do that for us. Um, we'll say uh name is equal to models dot I'm just going to copy and paste this in because I want to make sure that I don't go over time here. So, I'm gonna Oops. What? How we doing for time? >> Good. Okay. Um, so we have the name and then also the email. So this is kind of doing the same thing that I was doing in debaver but uh I'm doing it now in a python class and then I will do class present oops capital. So we have to kind of keep Django or Python's convention. So we'll use the kind of camel case for classes presentation and that will also inherit from models.mmodel. And to speed things along I'm going to just copy and paste these Okay. So we don't have to create this third table, the intersection aka join aka uh linking aka um pivot table because we have this and this will actually create objects that have um a kind of list valued attribute in the Python code but it will create this third table when we do the migration. There's another option here that we can put uh related_name and this would be this would put the a list in the presenters um oops >> yes so we're actually having to do a lot less work here and this is kind of typical of what you would See, if you had a modeling specific ER diagram tool, you wouldn't have to really worry about those. Okay, so now I have this saved. I will go in and edit the um the settings file. So that's in scale 23 settings and this is where you see the different apps that come with Django. So it's called the batteries included framework because it has all the user authentication and content types and um authentication built in. And so we're just adding to the already existing functionality. So we'll save that. And so now let me just do the tree command first. So we see that uh we're still where we were before. But when we do make migrations, manage.py make migrations, we will generate two files. So we're generating this talks migrations initial here and then we're also creating this empty database that we will populate in a moment. Uh so the next one is optional but this command called um I don't have that here this command called SQL migrate that will allow you to see the SQL. So if you don't do this command you'll be fine you will just kind of kind of blissfully be unaware of the SQL. So this is SQL migrate and then we have to specify the app talks and 0001. So this generates the two tables talks_presenter. So there's this convention where you'll prepend the app name as a prefix to the table name. So talks_presenter talks_presentation and then we create this third table talks_presentation presentation. So that corresponds to the third table that we created manually. Okay. So that um allows us to visualize that. But like I said, we don't even need to do that. Uh we could just skip ahead to this migrate command. And that's going to actually create all these tables and the talks app is just one of them. Uh let me just show also if we want to see the migrations file talks migrations 01 initial. So this is actually kind of cool because it's the Python representation of the create table statements. So these create table statements are represented as a class migration which is a list of operations. Okay. So that is now you just kind of have to trust me for a second that the tables are actually there. But um I'm going to go to this next step of reverse engineering where we will go from the tables that were created by Django and we'll see them as an ER diagram. So to do that what we need to do is go to debaver and then create a new connection. Um, so here we will go select. I swear this like seems like it's a different order every time. Oh, here it's right here. SQL light. And then we'll find the SQL file that we just created right here. Now go open and finish. So now we have this connection and we can do view diagram and so now we have a lot of other tables besides what we created. What we created is right here. So we see that this intersection table, join table, linking table, uh pivot table was created automatically for us. Uh we also see there's another example of this here. So we have groups and users and a user can be part of many groups and then a um group can have many users. Okay. So almost done here. Um so the last step is to view Django generated tables in debaver. Oops. To uh sorry to view the DB generated tables in uh Django um with this inspect DB. So I'm going to also copy and paste here so that it's a little bit quicker. Um, so what we need to do is go into the settings file again. So, Emacs scale 23 settings. py. And we're going to edit our connection to the database so that instead of being connected to SQL light we will be connected to Postgress. So, I'm never sure how specific Python is about the indentation, but probably better safe than sorry. So, now if we do manage.py py inspect db we need to install uv pip install psycho pg2 so we don't have the postgress driver in um in python yet but now we do so now if we do manage py inspect db we'll see that we generated the presentation uh table, the presentation presenter. Oh, sorry. These are classes that were generated from the tables and they convert the names. So, it understands the naming convention. It'll convert the to the camel case convention of the class rather than the snake case. And you can see that this uh presentation here we um I think that's where I kind of skipped putting the attributes here. So this is just to kind of refresh this is going from this original table here to Python classes. So it's kind of nifty and that's what I wanted to show for this talk. Um there's also uh this pi reverse. So this kind of idea of forward and reverse is kind of uh shows up in different areas and um I don't have time to run this but if you want to try it these are the commands. So this will basically generate a class diagram so we can see the classes oop that got created. I'm gonna go switch here. So none of the PDF viewers is kind of ideal. Here we go. So here we have the presentation and pre presentation and presenter tables or sorry classes. Those inherit from model and um you can see kind of these container relationships. So the presentation has a many to many field and a char field and a text field. So to wrap up, I we compared these two different tools and kind of showed their parallel features. Um and I showed PI reverse very briefly. Um it's kind of hard to avoid AI. Um so I left a part about AI at the end. So visualization is kind of a way to better understand AI generated code. And so you could use this technique as a way to visualize and we saw that actually in the last talk um in this room that there was like generating um interaction diagrams with mermaid. Um and also the code generation part is also a little bit like AI. So these tools came from the 70s and 80s and back then generating SQL code from a diagram was kind of like their AI back then the expert system era. So that's all. Um I guess we're running out of time but I guess maybe one or two questions. So um using Django and uh you know the reverse engineering stuff would you say that's kind of uh what you would prefer to do bootstrapping a new database uh bootstrapping a a uh new SQL database or Postgress database from from like an existing one like say you're you're you're migrating across SQL versions or or a new version of Postgress that's that's the ideal place to be using it or >> I think so So yeah, being able to change the connection and still generate the class files >> um allows you to kind of be at this ideal level of abstraction so you're not worrying too much about the database. I'm sure that there is like that I mentioned the leaky abstraction that there could be some issues that you'll have to deal with potentially but um I believe Django takes care of that um pretty well for you. All right, thank you very much. Give a round of applause for a cousin. [applause]