MongoDB shell

Loading...

Do curso por University of London

Web Application Development with JavaScript and MongoDB

486 classificações

Explore Related Videos

At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you

University of London

Web Application Development with JavaScript and MongoDB

486 classificações

Curso 4 de 6 em Specialization Responsive Website Development and Design

In this course, you will develop more advanced web application programming skills. You will learn how to control data read and write access using methods, publish and subscribe. You will learn how to access your database and server shells using command line tools. You will use the SimpleSchema system to validate data and generate input forms automatically. You will see a complete collaborative code editing environment, TextCircle, being built from scratch. At the end of this course, you will be able to: - use Meteor methods to control data write access - use publish and subscribe to control data read access - install and use advanced Meteor packages - add user accounts to your applications - implement complex MongoDB filters - use the MongoDB and meteor server shells - define data validations schemas using SimpleSchema - generate data input forms automatically using SimpleSchema In this course, you will complete: 2 programming assignments taking ~4 hours each to complete 4 quizzes, each taking ~20 minutes to complete multiple practice quizzes, each taking ~5 minutes to complete Participation in or completion of this online course will not confer academic credit for University of London programmes

Na lição

User accounts, packages and methods

Welcome to the second module of 'Web Application Development with JavaScript and MongoDB!' In this module we will learn how to use the core user accounts packages, customise the user accounts UI using third party packages and search for and add packages to an application. We will also look at how to query MongoDB collections from the command line and learn how to control data write access using methods. Enjoy!

MongoDB shell8:13

Conheça os instrutores

Dr Matthew Yee-King
Lecturer
Computing Department, Goldsmiths, University of London

[MUSIC]

We're now going to take a little aside and find out how we can actually look

at the underlying database, which meteor is working with in our applications.

So far, it's kinda been hidden from view.

It's just this mysterious thing that we can dump things into and

pull things out of, but there's actually quite a lot going on in there,

which it's really interesting to have a poke around and see what's happening.

So first of all, let's find out what underlies the user accounts and

the way we do it is with the mongo shell.

So if you're, let's just check if your app is running.

So if you run meteor, looks like it's already running.

So to access the mongo shell, we type meteor mongo and

that logs in to the local database server.

So the default database server in meteor is mongo and

when we first installed meteor, it actually installed the mongo server for

us as well as the meteor layers on top of that.

And indeed, the Node.js system.

So there's a whole bunch of components inside that meteor framework,

which is getting stored automatically.

We don't need to worry about, but we're sort of now gonna unveil one of those,

which is the database server.

And mongo is a standard database server, which is of the category kind of no SQL.

So we might call it, we recorded a NoSQL database.

There are other types of databases and some of them you can use with meteor.

For example, the SQL database is MySQL and PostgreSQL.

The difference between these and the mongo has to do with how you store your data.

So mongo is quite open-minded about how you kind of store your data,

you don't have to specify schema beforehand, like table structures.

You just chuck stuff in there and kind of get on with it and

that's really a nice way of working with data for certain applications.

So let's just see what's in there, anyway.

So we're logged into mongo and

what we can do is ask it, which collections it has?

Now collections may be familiar if you remember that in our JavaScript code,

we defined a collection called documents.

And when we created it, we actually specified a string containing the word

documents and that's what the mongo collection is actually going to be called.

And indeed, there we have one collection called Mongo.

So we can do db, which refers to the database and

the name of the collection, which is documents and

findOne, which will pull out a document.

There it is.

And actually, there is only one document in there.

So if I do find() count(), you see it gives me a count of one.

So that's because everybody works on the same document,

because we've only got a single document in our collaborative document editor.

How about users?

But you see there's also another collection in there called users.

The reason I'm getting confused between the word collection and table is,

in more traditional databases like MySQL and PostgreSQL, we talk about tables.

In Mongo, we talk about collections.

So there's a user's collection there,

so db.users.findOne.

There's a user account and

let's just see how many there are.

There's one and if I was to go back to my application and

actually create a new user account, you will see and

that test call it test2@test.com, testtest.

There's now two accounts sitting there in the thing and

we can look at both of them by calling find and telling it to prettify it.

If we don't prettify it, it just looks like this.

Just a kind of flat dataset, but pretty kind of puts some formatting in there, so

it's a bit easier to read.

So what does a user account look like?

Well, here is one here.

So we've got an id, which is one of these ids that we've seen

before created at, when was that user account created.

Then their password, which is encrypted.

So, I think I typed in testtest and

you can see that turns into a load of gibberish there.

So it's a good idea to encrypt your passwords in your database in case anyone

gives hold of the contents of your database and

then they'll just have all the passwords, as well.

So, encrypting them makes it a little bit harder for

people to then access the passwords in plain text.

So that's that and then we can also see if there's any other collections.

I'm just noting that the user's collection was created by the package.

So when we install the package and start it up,

the user's account package does a bunch of clever stuff and

creates the user's collection and then automatically puts things into it and

manages that for us all sort of easily done with that plugin,

then we've got some more stuff in the docs and ops I'm interested in.

So if I do db.ops.find().count(), let's see how many are in there.

Oh, 40.

Now it says, 40 things in ops.

What do they look like?

FindOne and you'll see that an op relates

to a document, which is interesting.

So if I do db.documents.findOne()._ id,

you'll see actually it's the same id as the only document in the database.

So this operation pertains to that document and let's see.

If I was to, let's run that command 40.

If I then start editing the document,

here is my some new text.

You see that created 67 new entries in the ops table collection.

That means whenever I'm making edits, things are being dropped into ops and

ops is part of the shared JS library and it's a built-in thing that every

time you make an edit, it automatically propagates into the ops table.

And the reason we can't just, you might think,

why do we need to store all of these edits?

Well, the thing is imagine someone's making all their edits on a mobile

device or a device with a poor connection and they build up all these edits and

they're happily coding and then none of it is getting through to the central server.

And then somebody else is busy hacking away and then you end up with sort of two

different versions of the document, because they're not instantly propagating

and this is, you can imagine that this would be quite common with lots of people.

And suddenly, they get their connection back and all the edits go blurting into

the database and we need to somehow make sure that everybody then has the same

the most up-to-date document and so this is the kind of magic that I've shared JS.

So it has an algorithm, which can collects all of the edits that everybody's made and

then somehow figure out what to show everybody, so that it makes sense.

So let's say someone's made a bunch of edits to a bit of text,

which they've then deleted, but

then the current editing it before the delete happens, that could be a problem.

So the ops table is keeping track of it, and there's an algorithm, which share JS

has, which works on that and turns it into a meaningful document for everybody.

So that's just a quick aside where we've looked at the mongo share and

found out how we can look a the underlying database and

the collections that are being created by these different packages that we install.

So yeah, just go in there, have a poke around and see what you can find.

[MUSIC]

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play