>> When it comes to extending or changing our base model in anywhere, there's a couple of different approaches that we can take. For example, within our user model, if you include authentication whenever you're creating your AdonisJS 6 application,

it's going to use compose to mix the base model with an AuthFinder class to get back the end result of our user model. This AuthFinder adds those functions like verify credentials,

it also secures our password prior to persisting it to the database. So those things don't exist on this model itself, those exist within that AuthFinder mixin. We have a lesson already on

compose if you're interested in that approach, but that's just going to add it on a per model basis. What we're going to be talking about here today is changing our base model as a whole across all of our models.

For example, within AdonisJS 6 by default, whenever we serialize our models, we're going to get that data back as camel case for those property names. If we instead wished to get those back as snake case,

we could of course change that on a per model basis. So there is a static naming strategy property that we can set to a naming strategy, and AdonisJS does offer

a snake case naming strategy that changes that serialization behavior out of the back for us. So we can use that here as an example. If we jump back into Hopscotch then, send this off,

you see that now we're getting back snake case property names here in our serialized model data. But this is just for our posts or whichever model it is that we made that change on.

If we were to instead switch over to our users, for example, we can see that this is still using camel case for its property names. So in order for us to change that behavior

across all of our base models, we need to change the base model itself. So I'm going to go ahead and remove this snake case from our post there and let's jump into our terminal,

stop our server, clear that out. Because to do this, what we want to do is create a preload file. Preload files run before application boots,

hence before any models are actually able to make any queries. So it's a prime candidate for where we want to change our base model. So let's do node ace make preload.

I'm going to put this inside of a lucid folder in case there's any other lucid changes that we want to make down the road, and we'll call this base model. It's going to ask if we want to register this inside of our AdonisRC.ts file.

This is where that preload is going to automatically run during our applications boot lifecycle. So we can hit "True" on that so that it registers. While we're here, I'm just going to boot our server back up. So npm run def. Okay, great.

First, where did that change occur? Well, within our applications route, there's this AdonisRC.ts file. Inside of here, there's this preload section.

This is where it has added a register for our new base model preload right there. As you can see by the preload above it, you can also set this on a per environment basis.

So if we just wanted this base model to be applied within our web application, we could set this to the environment of web. If we just wanted it within the console, here if I get our strings going,

we can see that there's just this console value that we can set within that environment. There's also test and REPL as well. Since this is an array, we can have this run in any combination therein.

But whenever we omit that, it's going to register within all of those environments by default. Then we had this file create inside of a Lucid folder. So preloads go inside of our start directory.

So there it is right there inside of Lucid base model within that start directory. All that we need to do is import that base model from AdonisJS Lucid ORM. Since this is a static property,

we can change it directly on the base model itself. So naming strategy equals, and we just set it the exact same way that we did within the model directly.

So let's see, snake case naming strategy, just like so. Now, if we were to jump back into Hopscotch and send back off our users, this is a suboptimal query with a lot of data inside of it.

So it is taking a second. But when we do get this back, we get it back in snake case now rather than camel case. We have removed the naming strategy from our post model directly.

So whenever we send our posts off, that too is coming through in snake case now as well, because our base model has been changed across the board for all of our models.

But what about instances where we want to change actual instance level properties on our base model? For example, with our users query,

that is including a count for our posts, the number of posts per user. On our model, those counts and extras come through on

an extras object that is omitted by default from our serialized data. If we were to jump back into Hopscotch, switch back over to our users, send this off.

We can indeed confirm that there's no extras or meta property here with that count on our user. So if we wanted to change that across the board,

across all of our models to include those extras within our serialized responses, that is an instance level property that we would change. So for example, on our user,

we could add in serialize extras and set that to true, give that a save, jump back over to Hopscotch, send this off one more time,

and there is our meta with our post count. I've stubbed each of these with, I thought I did 5,000, I did 50,000, no wonder that's taken a second.

But we get back our count with 50,000 posts per user. If we want to make that change across the board, what we can do is within our base model preload,

we can reach from our base model through to its prototype to change those instance level defaults.

So if we set serialize extras to true here, give this a save. Note again, we have removed that from our user model, so it's no longer applied.

But if we send this off one more time within Hopscotch, you'll see that we're still getting that meta with that post count coming through with our result, because we've now changed that serialize extras

across the board across all of our models. So there is a quick look at how you can switch the static, as well as the instance level defaults for your base model across the board

for all of your applications models.