Original subtitles

Before we actually right, any Firestar database code, we have to understand a couple fundamental concepts

about how fire stores database works.

It'll help us also understand what it is that we're actually going to do from a coding perspective,

but before that, in order for me to show you these concepts, we actually have to go into the database.

The first thing we want to do is click this database tab inside of the develop sidebar.

In here, we want to select create a database.

And we'll get prompted with one of two options now.

The first one is called lock mode, and the second is test mode, and this is essentially the beginning

security rules that are set up for our new Cloud Firestar database when we create it.

Locked mode essentially prevents any one from reading and writing to our storage test mode doesn't matter.

It means that anybody can read and write to our database.

Now, what does that mean?

Well, this is one of those concepts on the right hand side here.

You'll see what looks like an odd version of some JavaScript code.

And what this says is this is kind of like a rule that we can write inside of our cloud firestorm that

will either allow or deny different permissions of what people can do.

What do I mean by this?

Let's say you had a user that wanted to fetch all of the data related to the users, like they wanted

a list of all the users while.

If we were storing sensitive information on those users, we would not want anyone to be able to do

that, let alone modify that data.

So using this block of code here inside of our database, we're able to have the flexibility to control

what people are able to do and not able to do.

It's essentially like we're setting restrictions on what rules we want to enforce so that our database

is as secure as possible.

So we to begin want to start in test mode and we'll end up writing some rules so that we'll get more

secure as we go, but we just want to explore this for now, so let's enable it.

And it will end up creating our first database for us.

Now, once we're in here, that rules tab is actually those things that I was talking about, this is

where we'll see those rules.

The first one, the on the right side.

So here we can edit them, but we'll figure out that later, I promise.

What we really want to see, though, is this data.

So in Firestar.

This database is what's called a no SQL database.

It's essentially a fancy way of saying that our database consists of one gigantic JSON object.

There are two types of data inside of our database, and they're more conceptual, so the first one

is called a collection.

A collection is exactly as it sounds, it's like a group of objects, except those objects are the second

type of data called documents.

So you can almost see them as an array of things.

And each of those things can also have properties that point to other collections.

So let's do an example.

Let's say we add a collection called User's.

We'll click next.

And now we suddenly have this path inside of our database of users, and that is a collection.

And in this collection, let's say we added a new document, in other words, a new user, we can auto

generate the ID because every object or document needs a unique identifier so that we know that in the

users, the document with this I.D. is that specific user.

And then let's say they had a display name.

Of the value eowa.

So if I save this now in my collection of users, there is a document with the idea of what we just

saw with the display name of this thing.

You see on the right hand side is the document itself.

And then inside of this document we can actually add a collection.

So for example, let's say our user also had carte items, right?

Like they pick some items and they added it to their cart, but they haven't checked it out yet.

And in there will also generate a new ID because the first item they got was, let's say the name of

the item was Blue Hat.

So now inside of our users collection for this user of Yeva, he has a property which is a collection

of card items, and in that collection of card items, there is a document of the cart item, blue hat.

He could have multiple different items.

Let's say he had another one, another one with a unique ID as well.

And the name of that was leatherjacket.

So here we see our car items collection on our user EOWA.

Has this two items inside of it, two documents.

So that's essentially the main thing in our database, it just consists of collections and documents

and then those documents might have their own collections and documents.

That's the idea behind how things are stored in our database, but the way that we would query for them

is like so.

Now, we already know that we have firebase imported and then we have our fire store and we remember

exporting out Consed Firestar equals fire based firestorm.

With this, how we actually query those documents is we would literally say something like Firestar

collection, right?

Because we need we want that collection and then we're saying users, what this will query for us is

this collection.

Right?

It'll give us the identifier for this collection.

If we wanted to say go into that users and then find this document, we would say Dot Doc and then we

would pass it, the ID of that document that we're looking for, i.e. that user.

So we're saying, Firestar, get me the collection called users and then get me the document with this

ID.

And then from here, we can even we can still keep chaining and say of that user document that you just

got me.

I want his collection of cart items.

And then you can from here also do dock, right, and we can fetch that specific item we want whether

we want the blue hat or the leather jacket, we would just copy that idea.

What this is essentially saying is we're asking our store to get us the collection of users.

And then from the collection, we want the specific document with this ID.

So this specific user and then from that user, we want its property collection called car items.

And from that car items, we want the specific document with this ID.

By calling this chain, Firestar will end up getting us the object reference to this specific item nested

inside of that user's user car items and then that specific car item.

If we were to go back to our application now, the other way we could query for this specific document

is if we did it like this.

So if we wanted this specific document, we could also say Firestar doc and then slash users slash.

This of car items, this idea.

So this is equivalent to writing this, and if we wanted this collection of car items.

It's exactly as you would imagine, instead of saying, Doc, we would say doc collection and then we

would paste the string up until this point.

So these are the two main methods of how we can get documents and collections from our database.

Now that we know how to query for them, there will be ways and methods on these objects that we get

that allow us to update them as well, but we'll see how to do that when we actually start implementing

that code into our application.

What we're going to do is we're going to store these authenticated users that we get back from our off

library inside of our database, because right now these users are not actually being stored in our

database.

They're currently held inside of this authentication area.

And Firebase is aware whenever a user signs in whether or not they've signed in before because it is

storing those users.

But we are not actually storing those users in our database.

So there's no usage for us with those user objects in any relation to what we could do with them inside

of our database.

So let's see what we're going to do.