Hello friends. Um today I'm going to be talking about Ecto which is the library that is used to connect with your database for your phoenix applications. So Ecto is the primary, I would say the most popular library that ships with phoenix. That's why it's actually added by default for you. That if you go to mix the excess, you will see phoenix ecto and by default phoenix assumes you're going to be using sequel based database and it comes actually with postgres um dependency added right there. So, um, between these three packages, we accomplished a lot of what we want today, which is establishing a connection with our database. Um, if you want to use a new sequel database or something other than Postgres, you could simply read the documentation and change some of these libraries right here. So if you want to use my sequel for instance, all you have to change is this one right here. While if you want to change, say to Mongo db or a different type of no sequel database, you'll have to look for the right package instead of this Ecto sequel. But in our case right here, I will be using Postgres. So I'm just gonna keep all these three packages right here now, Ecto is really um powerful library that it gives us a lot of um capabilities to achieve what we want in our phoenix application. So Acto comes with basically six primary modules. So these modules are aggressions schemas query repo I think that for nothing. Um okay esto gives us variety of tools to connect with our database and as you will see it's very explicit in the way it does things which I think it's it's really good compared with possibly some other ones that may abstract a lot of the complexities that kind of ships with the applications. So that's why, you know, I think splitting things this way with Ecto is really good. As you will see later. It makes it a little bit more verbose, probably what you might be used to in some other Oh RMS object relations wrapping um but it gives you the flexibility and a lot of power to achieve what you want in a database powered application. Um Instead of going through all these in my lesson, what I'll do, I'll cover them as we go through. So our app like how you would use them as you go through it up. But before I go this let's let me show you a little bit about some of the basic setups that comes with our database. So if you go to Config and you go to death that he access, you will see right here and I mentioned this in an earlier cast that this is a configuration to connect to your database. So our database name here is dev notes death this death is basically just because it's it's development if you go to the test one, haven't modified that one yet but basically it will be it will do have underscored test and then the production one you'll have to set up the production one differently depending on where you deploy your application. So this is the name of our application if you remember we had to run a mixed ecto dot create to create our database um in order to for this database to be created and we have to supply the right to their name and password and the right host for our database. Okay. The other file I want to note right here is if you go to your lib and then you go to the main application folder which is definitely in our case you will see a um file called repo dot e x. As I mentioned, one of the modules, I won't be delving too deep into it today but it's the repo module. It's basically the way for us to connect um our application to to our report. Our database report. Okay, so this is the way to think of it like it's our gateway to connect with our database. A lot of the work we will do with the database. Will funnel through repo which is in this case our module. Dev notes. Repo, as you can tell, the first line here is use ecto dot repo which basically imports a lot of the functionalities that we get from our from from ecto So a lot of the functionalities you will see built in actually come by you by, you know using use from um the ecto repo manual. Alright. So most applications, the first step you would do if you want to build something is you wanna um start by creating your database table. Um and the way the easiest way to do it here is to do migrations, you don't have to have migrations. But again, it's a very powerful feature of the chips with Actos that you might want to just take advantage of it. So mix, mix, Acto that gen the migration, this is a task, the mixed task that allows you to generate a migration file. Now, generally speaking, I will actually be avoiding using generators a lot because I want to build things bit by bit just to show you how things are built and what each line means. Sometimes generators built a lot of files that could be overwhelmed. But in the case of migrations, the files generated is actually very simple. That's why I think it's totally worth um using the generator for it. So I'll name my, my migration, create notes, awesome. So if you go to your private prive or priv repo and then migration, you will see a new file added right here. Actually, another good reason to use generators for migrations is because migrations have this timestamp at the beginning of it because migrations have to get run in order. Like for instance, you create the table first, then you want to add a column to it. It doesn't work the other way around. That's why the order of migration is important. So in this case you see this timestamp and then create notes that the excess if you remember excess is electoral script, which means that the file will not get compiled. So that's an important thing to keep in mind because this file does not get compiled, which means it could contain an error. That's why generally speaking, you know, um try to, you know, make sure you put as little code as possible in in in this file and try to avoid putting a lot of logic into it as we will see you later. So the module, it's automatically has this name space deaf. Notes, repo migrations, create notes. And then you see it's using this actual migration. So a lot of the functions that we have available for us right here. So for example, this death change is basically imported broad from this ecto migration. Now, the good, I want to show you here again. You can always find in in ecto phoenix. Um, you will see basically a lot of the code, I will show you right here. So for instance, if you wanna see something about migrations, what I usually do with actual migrations and then the first result is usually the one you will get Is the one you're looking for. So you see at the very top some good samples right here. So with migrations, um you either have this change and then you put the change you want. Um, and um or you could have an up and down and I'll show you what that means means in a second. Awesome. So here migrations, maybe I'll put this in the notes. No traditions are used to create your people structure in your database. There's really more for structure and less about the data. So anything that has to do with structures like columns, indexes, constraints um for some other things that have to do directly with the database, you basically use migrations for it. Okay, so run migrations, you execute mixed up migrate fondue or roll back migration to execute mix ecto. Each migration has to be written in a way you see when you think about it is that you should be able to execute the migration and there should also be a way to undo the migration. So in our case here, I'll just simply use a code similar to the one you see here create table, let's call our table jumps and then we open up unlock and then here you specify all the fields that you want in your table. So you can say something like add title has to be a um and adam and then you say, well it's a string and then you could even say something like null falls. This basically tells the database that you basically don't want this table to have null for the title. Let's say we require all no titles to be um to be present. Um And then let's see here we add the body, you know, in my case what I'll do as you will see later here. I'll add the body text and the string. Also we expect this to be present for our notes. And also I'm gonna add body html. Actually, instead of here, I'll call it M. D. For markdown. And then bodies to melt. The way we're gonna build our app is we're gonna allow developers to enter a title for the note and then enter a body for the note as well. And the body will be marked down but then we convert it and restore it as html. Um so that it's displayed nicely on the page. Also we expect this to be false. If there's nobody or titled then there is no no there will be other things we want to add for our um table. But what we will do here is we will um do time stamps and that will create timestamps which is inserted at. And objects that actually those are automatically set for us by extra. So extra will automatically set those two fields. They're very handy because whenever you create something it would be no good to know when it was created for things like sorting. Um And also when you update something, it would be good to know when it was last updated. That's why I would recommend um having those um timestamps on every table. Also some picture not here. Ecto migration automatically add primary key which is I. D. Which will be an auto increment. So I. D. Will start at one and then until auto increment that's automatically added for you. So you don't have to add it automatically. Awesome. So with that in mind let's surround the task. I showed you earlier mix ecto dot migrate and that will migrate the database. So it didn't show us any error. So this is notice it says forward. Uh It created the table notes. Now if I do mix ecto that roll back it will actually drop the table notes. Okay, so in this case here it says backwards and here it is forward. So undoing a migration is simply running the reverse of the migration. If it is not intuitive, like in this case, actor will automatically um No or let's say guess that because you said create table here, the opposite of it. The backward of this is to do drop table. But if it wasn't the case then you could simply do a deaf up to do the migration forward or the migrate and death down to do the um reverse of it. So in this case, drop table. If you notice the example here shows you that exactly in this case, in this particular case actually they could have just used change but in some cases the reverse is not always straightforward. Sometimes certain things are non reversible. So that's why you may want to have an up and down. But in our case uh this is a simply reversible migration. So that's why I created a, you know, a just a change function that will do both. And then in the case of the rollback it will get its drop table. Um One thing we may want to do here is um we may want to do an index. So let's do an index on the title for now. Again, we may want to think a little bit more carefully about in indices going forward. Like for instance, it may be a good idea to index both the title and the body. Maybe we could we could actually do just that. So add index on the notes table. And then you open up a um a list and then you just say I wanna uh index on the title. It doesn't have to be a unique index. Maybe we allow different notes to have the same title. Maybe, you know, we won't enforce that at the moment because you know, sometimes different depths may want to take different notes and they may use the same title. And also let's say index the body. And let's index the MD. Instead of the html. So, you know, if we're searching for a particular text, we could search for a particular text on the body that was inserted, which is usually pure text instead of instead of someone again here. If you need more information here. Um you know, you can either Look at this one. This is index. There may be some good example here, yep, it's right there. So create index posed name and then added a comment to do it. Index comment. So, but you see this one right here. And by the way, um also Ector will automatically guess that by the way, I made a mistake here, it's not add index, it is create index. I'll change this to create index. So Hector will guess that the rollback of this one is job index. So you wouldn't have to worry about it. So it makes sense to migrate the several checks. It's actually working. It did work. It created the table notes and then it created also an index on the title and an index on the body. There's a lot more features for for the migrations. Um so I just showed you the basics right here. Now. Next up here, we need to connect somehow to this table. So we created the table in the database but it would be good to connect to it. So how do we connect to it? Well, ecto or actually say, you know, Ecto and phoenix doesn't enforce a particular structure and doesn't actually enforce that. You only have one module that connects to this table. You could have what's called a schema that you could connect multiple tables or sorry, multiple modules to the same table. So that's why, you know, you have to think what would be the best place for us to put something like this. Well, in this case here I have lip dev notes and I just have my application E X. The mailer and repo which are all three files that came with our application generator when we first generated. Mix ecto dot new. Sorry, mix um phoenix, not noon. So we have to think here, where do we want to put that note module that connects to that notes? Um table? Well, one thing I would recommend here, again, the simplest way is to simply just create a note here as you will see later. It's generally better to have it in a sub folder. So I'll have a sub folder called notes. And within it I will have a file called note E X. This has to be an execute double compiled file. So I put the X. And then here I put deaf module and then here I'll call it left notes. Make sure you follow the right naming convention for the folder structure. So they have notes. Notes and the notes have notes dot notes dot No, that's how the best name this model one right here. And I would recommend this because as our app grows, you're gonna have notes, you're gonna have maybe we'll have tags. Maybe we'll have user accounts. It's better to organize them in separate folders instead of keeping everything flat into your DEv notes. Uh The primary, they've known library folder right here. So again, lip Dev Notes, Notes. And then note, we don't have to put the lip here in the module name. We just start with dev notes and then go notes. No. And then we could start to import all the functionality from Ecto. And then what I'm going to be using now is ecto schema. So Ecto schema is another partial module that come with ecto that we're gonna basically make good use of when we are connecting to the database. In its simplest form here, we noticed that we simply call this, you know, function right here and then we give it the table name in this case. Notes Yeah. And then we define all the fields that map to the database. You know, you may be wondering like some RmS, you may be used of It automatically reads the tables from the database. Um and it automatically maps or generates functions for you for each one of those columns. It's not the case with, again, as I mentioned at the beginning of this lesson. Actor is more verbals. It actually likes you to be explicit about a lot of the things. So in our case here we will simply define our fields. So we go and put field and then title and then it's a string and then we go filled by um and B. It's also a string and then body. Html and then it's also a string. So that's basically a way for us to define um how we're going to connect this module to um to our um database table. Okay, awesome. So in order to keep this lesson short, I'm just gonna stop right here and then in the next lesson, I will show you how we could use the repo module to actually query this note stable. Thank you for joining in and I'll see you in the next lesson.