Okay, so we had an introduction to SQL, the structured query language, that's used to interface with a relational database management system. One of the SQL implementations out there today is Postgres, very popular one, that's open source. It's not tied to any one company, it's a very nice one. I think it's even nicer than MySQL these days. And we're gonna talk about Postgres in the context of the application we are building so that we can design our database tables to take care of the messages that we posted aboard. And maybe we can also do the users table because we need to know who posted. So you have to install Postgres from this website, you click download, choose your operating system. It should also come of the graphical user interface that we are going to use, that's called PG Admin. So once you install PG Admin, it should look like this. So I'm gonna press type that, and you can have this interface. Now, before I jump into that, I just wanna refresh your memory about what we're doing with the app. So if you recall, we had like a React application last time we were doing stuff. And this React application had some app with some messages. And these messages are coming from this backend. That's fake. And I'm gonna show you what the response looks like. So open a new tab in my browser. This is the response, basic and array of object. And each has a property that we are interested in title. And we're gonna do today is build a database table to hold each of this piece of information. So in the context of the application, let me power it up just so you see. I wanna CD. By the way, I should point out what's the repository that we're using, in case you don't have it. Let me share. I use the source code for this repository here. Post the link to the Zoom chat. And I'm gonna CD to web client. NPM starts, you can see what the app looks like. So... Okay. Got it loaded here. Basically a very simple app where you press write message, it adds a message to this kind of message board. You can think of this as the function that every social media has. You can comment on somebody's picture or video or whatever. It's pretty much the same, very similar. So this data is coming from our backend. That's fake, but we want to build our own. That's the goal. But to get there, we need the first backend server and then the database. And now we're dealing with the database, see how we're going to design this. Then later we're going to stage things together with the express in another lesson. Okay, so let's go and back to PG Admin. So you got the point. Just messages. Usually there's the author of the message. There's the date where it was created. Maybe you can edit and there's an updated date. So there are many attributes or fields that we can think about when you want to store information about a specific message or comment. So I'm going to go to PG Admin and first you want to make sure you have a server here. If you expand, you want to have a server. If you don't have one, you right click register server. So you can call it whatever, let's say postgres local. In connection, you should add local host, which is just a latest for 127.0.0.1. And then you got the database you want to connect to postgres by default and username is postgres by default, even though they're the same and they're distinct. And there's a password. Let me see if I remember my password. So the password is usually set up when you install postgres. Okay, that worked, it seems, yeah. So here's my postgres local, I can expand and expand databases, I can see all of these. I already have some, so you should at least have postgres default database there. But we're going to create a completely new one. Now to do that, I'm going to, usually you want to kind of isolate your database with different user or roles. So when you hear role, that's also called a user. So I want to create a separate user just for us to access the database we're going to make. So I'm going to expand login group roles, create, right click, create login group role. And give a name to this user, I call it full underscore stack underscore user three, because I already have full stack user there. And then you can go through the definitions here. You can add a password to the user, make sure you don't forget. And you have to make sure on the privileges that it can log in, otherwise you can't do anything, at least that. And then the other ones don't really care. And like I mentioned before, if you click SQL tab, you can understand what this clicking of the user interface is actually going to do behind the scenes. Because PG admin is just a front end. For the back end, that's the actual SQL queries that are run. So if you were to do this manually, you would have to type or write this SQL query here. Okay, so the nice thing about PG admin is builds the query for us. So we don't have to remember specifically the syntax, so you can just go by mouse clicks through the interface, and it will build the statement for us. Also a good way to refresh your memory about how to do things in SQL manually. So you can, oh, okay, this is the create role statement. You give the name of the row or user, and here all the kind of privileges and the password at the end, which doesn't show that. And then you can click save, that's going to run that, and you should have full stack user here. Now I'm going to use this user to create, to own a database. So I'm going to create a database here by right click databases, create database. I'll call it full underscore stack underscore DB three, because I already have the DB without the number. For the owner, I'm going to change that to the user I just created for full stack user three. For the definition, I don't think we care much about the stuff. Security parameters advanced, we don't care. If you go to SQL, you will see this is what's going to be run. So the statements call create database, give it the name, and with the owner equals that, and then some other stuff like encoding connection limit is template. So if you were to create a database manually, you would pretty much do this command, although I think you can just simplify to create database with owner. And the others will be default. Anyway, it's going to run that query to create the database. So I should have it here full stack DB three. And within that database, you can expand schemas public, which is the default one. So you're going to see public dot table name a lot. So keep that in mind. And then here we have all the resources like the tables. We have sequences, procedures and other stuff. So we're going to focus on tables here. So we're going to create, let's first start off with a table that will hold data for the messages. So we can right click tables, create table, and then you can give it a name. Let's call it messages. The owner for the table here, I mean, doesn't really matter, but you can use full stack users three, I guess. And then columns have, so let's add the primary key. Remember when we have database tables, usually we always add a primary key, which is a unique identifier for the rows. Remember when you had a table of customers to or more customers could have the same name. So how do we distinguish between them? It's with the ID, the customer ID. So in this case, it's going to be the message ID, which typically we just call ID for the column. So you can give the name ID. Now for the data type in Postgres, if you want to, it could be integer or usually these days people use big int because big int gives more, a maximum value higher than the normal integer. So you can try using that. But the thing with Postgres is usually you want to have the ID automatically increment. So it starts counting from one ID one, and then when you create a new record, it should be ID two and so on. The way Postgres accomplishes that is through a sequence. But to do a sequence, you got a set of default value with a function called to next valve, which you might not understand how to do it. So here you can just choose what's called a serial type, which is actually going to map to integer as we're going to see later. So you can either choose serial for integer or a big serial for big int. I'll do big int so you can see big serial here. And then we're going to mark this as a not know column because we don't want the primary key to have like kind of no value. Now it's like a value that's not set yet. We don't want that. We always want to have a value there has to be an integer. And you want that to be a primary key. So you want to toggle that as well. Now if you go to the single part, you see it already creates the create table command that we would type manually under the public schema dot messages, which is the name of the table. And then we have the definition for the column here, which is the name ID, and the type is big serial and not know is that constraint that we toggle. And the other toggle adds primary key parentheses column name ID here. So it's saying, hey, the ID column will be the primary key. And there's other stuff here, alter table, change the owner, because we change this owner here. Any case, go back to columns, don't click save yet. Okay, what else do we need to store for the information? Okay, since I just had a crash, and I had to open zoom again, I'm going to just recall what we were doing. Basically I created a new server by register server. And then after doing that, I have postgres local server, I created logging or group row. So let me know if you haven't heard that part. And then full stack user three was the one created by right click create here. And after doing that, creating a row, I went to databases, and I created one here. And I gave the name full stack DB three. Now expanded that scheme as public. And under that, I can have many resources like tables and sequences. So for the tables, I was creating a table by right click tables and create table. This table will hold the information for the messages in the message bar. So I call it messages table. The naming condition that I follow is a lower case for the table name. And if I want to separate words, I use underscore. For the owner, you can even either leave full stress or you can add that one that we used. And here I was creating the table for the ID, the primary key, which is usually used to distinguish between two rows. And I call it ID simply. And the data type can be a serial. It's because if postgres needs, if you want to auto increment the ID fields, you have to use the serial which in the end is going to map to either integer or big int. If you use serial, it will be integer. If you use big serial, it will be big int. Big int is what people like to use these days because it allows for higher values of an integer. Whereas the integer might be too small because they have so many millions of users now. Anyway, I'll do it for you, big serial. And this is going to be the primary key. Therefore, I don't want it to be something that cannot have any value. So I have to mark it as not no, it always should have a value. And also make it the primary key. And once I do that, I told you that I can click the SQL tab to see what the SQL syntax would look like for the create table statement. And you can see here's the column definition big serial with the not no constraint. And then also a statement here for the primary key being the ID. Anyway, going back to columns, that's where I was. So what other information can we hold for a message? Obviously the text itself, right, we can take that. So what do you want to call it? We can call content or title or body, whatever. Let's call it body of the message. And this is a sequence of characters. So it's a character varying. So you're going to type character varying, which is the same as their care, okay? If you see their care is the same. Make sure to select the one without the square brackets. Don't make that mistake. And you can give the length of precision here. You can just start up to 55 characters at most. And then you can adjust accordingly later if you need. If you want that to not be no, you can mark that or that makes sense, right? Because you don't want empty messages, so you don't want that to be no. And it's not a primary key, so I leave that out. I don't need a default value, so it's blank. Another possible column that I could have is the person who wrote the message. But if you recall from a previous lecture, usually we separate resources with different tables. So we're going to have the table for messages, and then we're going to separate that with a table for users. So here we would have what we call a foreign key, which is the ID of the user. And that ID will punch the primary key of the user's table. So you can give it, if we call user underscore ID, that is descriptive of what it means. Or you can call author ID. That's also very common. This one is either going to be integer if that table for users uses a primary key that's an integer, or a big int if he uses big int. Since we're doing big int, everything here, I'll just add big int for you. And yeah, if you want that to be no, meaning do you always want an author associated with a message? If so, you want to mark this as not no. Otherwise, it could have like orphan messages that nobody knows who wrote it. Anyway, you can add more stuff like, when was the message created? I usually call that created at created underscore at. That's one of the names. And that's going to be a date, but there's multiple day types here. There's the date. There's timestamp with time zone. So I usually, when I use an object relational method like SQLize, it uses timestamp with time zone. So I'm going to use that one. That includes, you know, when we store time, usually want to store in UTC, which is basically a universal time. So that's no confusion. Like, okay, somebody created a message and they were in Western U.S. And then somebody created in the Eastern. How are we going to store separate dates? Like, how do I know what's the time? So you usually want to centralize, normalize everything to UTC. And then when you need to show the date to the user, it's going to be converted to the time zone they are currently at. Anyway, enough of that. Just put a timestamp of time zone. And you could have updated that as well. If in case you want to be able to edit the message and you want to keep track of when it was updated, and it could be the same timestamp of time zone. And then you can keep going on and on with whatever you want to store for messages. Oh, anybody else? Anybody has a suggestion for what to store? What else can we store for messages? Okay, let's go then. Let's keep it that if you need to add more columns later, you can always do it. Okay, let's just verify. We have this tab for constraints, and this is where you can add constraints such as uniqueness, primary key, foreign key, and so on. Okay, I can actually go here and click foreign key and add that user ID as a foreign key to the user's table. But since we don't have a user's table, I'm not going to add it right now. But you could add it later, okay? You just click here and basically we'll add, give it a name, whatever. Usually there's a convention, like I think it's my ORM, for example, SQLized. It does the table name and then user ID, F key, which stands for foreign key. I think that's the naming convention. And then the definition would be the columns would basically you choose this one, references some other tables column. Since we don't have that, we cannot select it here. Anyway, I'm going to leave that off. We're going to trash it, and then we're going to do verify, okay, we've got ID, body, user ID, you see big int, created add, updated add. Sounds good. Save it. We now have the table messages here. I can expand, and I should be able to see the columns here. If you ever need to change the table, you can right click. You can right click, and you can click properties. I know it's hard to see. I usually scroll up so I can right click and see the bottom here as properties. And you can go to columns again and add or remove or change them accordingly. Okay. Now let's right click a view added data all rows so it can do a select star from messages. You can see it creates the query for us, and it even adds the order by. And if you want to run it again, it can click play through this query tool here. Right now, there's no records. You can see empty rows here. So if you want to add one, you can either do it manually of SQL, or you can use the graphical user interface. If you click this plus, you should be able to add one here. For example, the add hello world for the body, okay. And then user ID, we don't have any. I'm just going to add one. Let's make believe there is a user ID with ID one and created that. I can add the current time by calling this function now parentheses. And that should create the current time. And the same for the other updated ads. And I think I can just leave the ID. Let me let me see if it works. If I leave the ID out with it, will it auto increment and take the next available one? It did. So it added one there. So as you can see, it changed the created ad to the timestamp with time zone. Calling out a function now gives us format, which is the year, the dash month, dash day, space, and then the time. And then there's, I think there's a time zone aspect here, which is my time zone is minus four from UTC, which is Eastern time in the U.S. And the same for updated ads. Okay, so you can add more. Let's try using the query tool like I showed you before, but I want to reiterate that. But before, let me ask, let me see if somebody has a question. Does postgres have a Rob data type? Yeah, has binary data types? If you go here, it does, you can go to the column section, click to add any column and just click here to see what types they have. So you can see all the types that postgres has by scrolling down here. Okay. So all this stuff, JSON, vector, polygon. All that stuff. I think you're talking about binary. I don't think the name is blob, but it's something different. So you'd have to look it up in the, you know, do a search, but there's a specific name. I'm sure it has. Just don't know the name off the top of my head right now. Can email address be captured? Absolutely. Email address is just a character varying. You use that for emails. All right. Let me delete the row because I don't want it or just close this. Anyway, I'm showing the query tool again in case you haven't seen from a previous lecture. We have these tools available through the tools menu. So there's the query tool here, which is the one we're familiar with right now, which is basically you write the queries. You like select, start from messages, semicolon, you press play or F5 on the keyboard. And you should be able to see all the rows or messages. And you can do more stuff like limit one, you just want one and order by something and so on and so on. So you can also do the insertion. Let's inserting to add a new row manually. So you would do table name and then value. Since you don't know the order, you might want to have it on the left-hand side. Here, for example, ID body, user ID, rated ads, updated ads, and so on. Now, if you forget how to do this for some reason, oh, I forgot how to do insertion. I don't remember. You can do the following. Let me show you. Right click the table name, scripts, and you can click insert script. And it will automatically generate one for you like this. You see that all the columns are written out. And you all you have to do is substitute the question marks here. So I think I'll use, for the ID, I can use what's called a default. So it will take the next value in the sequence. And from the body, let's say another message with quotes and user ID. I don't have a user. Let's put just one, make believe that he exists and created that you can call now to get the current time zone timestamp string and the other one as well. Click that and we got a syntax error. Let's see what's going on. I wonder if it's default. Let me see. If I omit the ID, will it work? Okay. So I have to remove the ID and remove it. So it's omitted and it will take the next value. All right. So I can be able to either run the query manually here, select star from messages, or use the graphical user interface. And I should see the second one with the ID too. Okay. So you can do anything here like order by ID descending, which is basically going to take the rows and look at the ID and do it descending. So the two is going to be first and then one. That's how you order things by the column. If you want to send it as the default, either remove it or put ASC. Okay. So that's the query tool. If you like command line, you might also look at the piece equal tool. This one is, I use a lot for production servers because I need to SSH to virtual machines. And I only have the command line. I don't have graphical user interface. So this one is very nice for that use case. So I would just do queries like select star from messages, like that. And I can see all the rows and do whatever. And do whatever you cannot aware. Okay. Where the ID of the message is equal to. So I only get another message and so on and so on. You can do all the SQL queries. There's also many commands that you can learn from the piece SQL. If you type, I think, let me try backslash question mark. That gives you all the piece SQL commands. For example, if you want a list of the tables, you can do it backslash D. If you want to list or describe the tables backslash D and then the name of the table. And so on. Let me demonstrate backslash D gives you all the list of tables sequences and stuff other stuff. And if you want to describe or get the column information for messages backslash D messages table, it will tell me what the column and their types are very useful. If you're working on a database and you need to add a new column, you want to verify that your statement ran successfully. So you would use this. Okay. You can also get help of actual SQL commands. I think you can type help. Let me try. And that one is backslash H. You see here, get help of SQL. So you can do that and we'll tell you all the actual commands for SQL. Alter, copy, whatever, create table, very nice. If you know what exactly, oh, I want to create a table. I just forget exactly. So you can go here, I'll create table. Obviously you can always do Google search or ask your chat AI chat bot how to do stuff. But this, I think it's nice if you already have a understanding, you can have a reference within the commands here. Okay. Great. How about we work on another table, the users table. So let's do the same approach. It's always the same. There's no secret. You're going to go here, do the create table. Let's call this users. If you notice my naming convention, I use plural name for the column for the table names. If you want to give a different owner full stack, user three. Schema usually public unless you have a complex database with the different schemas. And then columns. Let's see. We always have ID, which is the primary key. So let's do big serial and then not know primary key. And then what else we start from a user. Somebody asks, can we start the email? Yes. It's just character very. Let's do that. And that's how many characters can we have for the email at most? I think I look it up once and I have in my my apps written there. But I cannot recall. Let's put 1024 so you can change it later. Not know. I don't want the email to be no. And we can add more stuff there. I don't know username. If you want that, like the display name or username, screen name, whatever. That's a character very as well. And you can give the limit if you want to be at most 255. I cannot be no. And then you can go on and on. Okay. When was the counter user created? We can add that time stamp with time space zone. And we can have more information. I don't know what else you want to track on the user, but you can always add later. If you want to add constraints, you can go here. Maybe one constraint we want to think about is can we start multiple users with the same email? That's usually something you don't want. So you want to add a unique constraint for the email here. Let's go. Click unique plus. And let's call this at the convention is table name. So users underscore the name of the column, which is email. And I think they call it UK or something. Yeah, it doesn't really matter. Just give it a name here. And then we can go to the columns definition here and you want to choose email. This is the same as adding an index, by the way, like you might also see adding the unique constraint as adding an index to a column. So that it cannot have multiple rows of the same value. Okay, I think that's enough. And if you look at what's going to generate, this is it. And you can see the constraint at the end constraint. Call this unique email. This is the column name that has to be unique. Maybe you also want to do the constraint for a username, right? You don't want people with the same username. I know that some systems don't allow you to have the same username as somebody else. So you can also add a unique to that if you want. Anyway, click save and you should be able to see users here and their columns. Let's run some queries of the query tool. You can also right click here and click query tool to open it. And let's say, I don't have a user, right? So let me, how can we add it? Inserting to, if I don't remember, can just right click, script, insert, and just fill in the values. I don't need ID, so I delete it. So it's auto incremented. And let's say, hello, say Anna nail.com username Anna created. I'll be the current date, which is the function for now. And if I do that, should be able to get it. Now, what's going on here? Values, syntax error near now. Let me check one thing. Sequence for, I got the sequence here. Now, why is that erroring out? Oh, let me see. Properties were created at timestamp time zone. Why is it doing that? That was strange. I clicked it again into work. Something must have not saved before executing the query. Anyway, that should work. So I can right click and view all the rows. And it should be there. Now, if you want to try adding another one of the same email to see if the constraint worked, right? We cannot have two people with the same email. That'll be, so I'm trying hello here. I'm putting now. I'm going to save. It doesn't let me do it. Key email already exists. Duplicate key violates unique constraint. So whenever you add constraints, you want to always validate that it's working by doing this kind of test that I did. So I basically had two people the same email. It doesn't let me. So I have to change to maybe Anna too. That should work. Okay. And there you go. Okay. Now that we have users, we have messages here. Let's learn how we can maybe get all the messages for a specific user using a join. So you would, you can use the query tool here. And select star from let's do users first. So we get all the users. And then we want to narrow it down. So where the user ID, the ID is one. So if I do that, I get the user with ID one. Then I want to be able to get all of that user's messages with an inner join. So I'm going to go here before the way our inner join to combine the tables and match with the primary key and foreign key. So we're going to inner join the messages on. So we want the messages. User ID, right? That has to match the user stable dot ID. I'm being very explicit here on the, because I put a dot here, but you don't have, usually it, it, you can put omit that. So if I do that here, let me see. It's telling me, it's telling me that I'm going to do that here. Let me see. It's telling me that ID is ambiguous. Now that we have a join, there's an ID for users and ID for messages. So here you want to be specific. In this case, I want the user one, right? So it has to be the user's ID. User stable ID column one for the filter. Otherwise I would get everybody's messages. What else is going on? Syntax error. That was strange. This, I click again and it's working. There's some, some stuff going on here that's not saving my thing before executing the query and gets giving me errors. But anyway, here's what I got for the join. So I can see all of the, the user's messages. So Anna here has all these messages. So if you recall from the join that we did in the previous lecture, basically we have this left-hand side that's from the user stable. And we got the right-hand side visually, as I see it, is from the messages table. So if I read this, I'm looking to see this part here, which is letting me know all of the user's messages. Hello world, another message, and so on. Now if I don't have the where, that's going to be everybody's messages. So if you do that, you're going to get messages for everyone. Now I don't have any messages for all the other people, so let me just add new ones here so you can see. I'm going to add a script for in search for the messages. And let's do remove ID, a body, let's say hello. And user idea, I want to make another user, okay? Number, let's do a three, the one we have now and now. And I can do it multiple times. Currently, there's no constraint for the message body, like I can spam multiple times. So I can go back to that, clicking close, and go back to what I had before here and execute. I'm going to get everybody's messages there. I can see user three has all these hello messages. So if you want to narrow it down, let's say where user ID is one, I should only see for the user, oops, users.id. I should only see for user one, hello world, another message. If I do a user ID three in the where, I should only see for user three, right? Hello, hello all the time. And that's how I test it, that it's actually working, my query. Yeah, so I just acted like a spammer here. So in the actual application, usually we have spam protection. So you would check, hey, has this person made the same comment within the 24 hours of the same message? Maybe I can find some rules to apply. If you write the same thing in the same post, in the same photo, for example, that says the same message within 24 hours, if you do more than 10 times, you're considered a spammer and we're going to block you from actually creating the message. So you can do that with the backend server logic. So the backend server is like a gatekeeper to the database. So first has to pass through it in order for the data to be created. All right, so now we got users and messages and let's go back to that. Actually, I wanted to show you. I just want to check users again here, right click. And I cannot see properties, but it's here. I think this one. If you look at columns, it changed the big end, right? Remember, we had big serial. So when you create the table, we have a big serial. So when you create the table, we have a big serial. So when you create the table, we have to put big serial, but that gets turned into big end here. And it adds the default value next val with something here. That's basically using the sequence. If you look at sequences for the users, for example, you can look at properties. It's basically selling what's the maximum value for the ID, what is the start value and what's the current, which is three, right? The last user had the ID three. So next time you create something, it's going to auto-increment to four and it's five and so on. So that's the mechanism to auto-increment in Postgres. Okay, if you want to know what a table is created and you forget, you can always right click the table, scripts create, and it will give you the content for that here. Same thing for everything, everything else. I think if you do it for columns, it will give you a statement to alter the table, add the column. Very handy if you don't remember SQL syntax. And indexes, rules, triggers, constraints, if you want to right click, create script, it gives you the code for how to add a constraint. Basically, alter the table, add constraint, the name, and then primary key in the case ID. And the reason for adding constraints, for example, the foreign key, like I told you, is something to do, okay, what happens if you add a message with a user ID that doesn't exist? Is that allowed? So if you add a constraint, foreign key constraint, it's going to check, okay, do we actually have that user? Something like that. They're never going to prevent you from actually adding it. Because I think right now, if you recall, when we add a new user, even if the author doesn't exist, it still allows us to do it. So if I do insert into messages, let's say hello there, user 999 doesn't exist, right? Let's try. And it allowed us to do it, and you can view the data here. And it's here. Now you could try to add a constraint, create a foreign key. Name is, let's do messages table name. And what's the call user ID? FGK, columns, user ID references, the user stable ID, right? References user stable ID. And add, I think I have to click add. Yeah, there you go. And this is the sequence that's going to be created. And click save. Let's try that thing again. Adding a message hello there too. And you see what happened now? User ID 999 not present in the table users. So it violates the foreign key constraint. So that constraint, you prevent like messages with users that don't exist. Okay. So that's one of the uses of constraints. Now I must tell you, maybe some companies don't use this, because their database has to serve like millions of people. And for some reason, their database system does not scale. Like if you have only one database with foreign key constraints, so that might like, how can I say it? It might hinder their approaches to scalability. So sometimes it's not good to always be using these things if you have a really large scale database, because what they do is they kind of create multiple databases, like multiple copies. Basically have a primary have secondaries. So they use the secondaries to explore other people to read from. So it doesn't overload the primary, which is usually used to write new data. And all the, like the new data gets propagated to these copies. So that way you can scale your server to many users. For example, you have 100 million users. They cannot possibly heading the same database instance at the same time. So you have to distribute the load. So what you do is create copies of the database. If you want to look into that, that's part of the, for example, database engineer would do that, look into that kind of stuff. So anyway, that's why sometimes we don't follow the we don't follow the standard convention of things, like the foreign keys and all this stuff. Sometimes you might need to hack stuff and not use it. But anyway, that's the gist of the basics. Now that we have tables and we can make queries, the last step would be to have a back end, actually write to have those queries be executed every time the client in the browser requests the resource. Or for example, when I go into the page for the app, right, I need to call the back end, hey, back end, I need to all the messages to show the back end would then say, okay, after checking that you're authorized not to take it in your system, I will ask the database make a basically make a query select, start from messages, get the results, give that back to the client, show it here, and then do the same if you need to write a new message. When I click the message, ask the back end, hey, I created a new message. Can you start out in the back end? The back end, okay, I'm going to call the database inserting two messages, this new message, and then I got the response all okay, and then I'm going to tell the client, hey, all good, the message is written and they would show here. That kind of stuff. But that's for another lesson.