 I work for MongoDB, and I live in New Zealand, but I'm American and I origin from New York. I became a lot of gems. They all do it at MongoDB. The Mongo gem, which is the driver of the database, there is MongoID. MongoID 5.0 depends on origin, which is the current ESL. Then there's BISON, which is the gem that does the low-level serialization, de-serialization of Ruby hashes to the BISON data type, which is the data type of the database. Then there's a gem called MongoPrograms that provides a reprogram authentication to the driver, which I don't think anybody uses. I think there's another one, BISON Extension, which is the extension for an older version of the BISON gem. I had this idea for the last minute, last week. I'll give you some context for why I wanted to talk to you, just have more of a discussion. This is an initiative that I wanted to do at the conference, but I think that the conference might be too grand of a context for me to do this. I've been maintaining MongoID for one to two years now. In working on MongoID, I know its strengths and weaknesses. I know the strengths and weaknesses of Rails through working on MongoID as well. I know strengths and weaknesses of MongoDB. I'm curious to hear why people don't choose to use MongoDB with Rails, what some of those reasons are, what your honest, frank, raw opinions of MongoDB are. I want to get more people to feel comfortable using MongoDB with Rails, even though it might seem like a square getting into a triangle. I didn't write MongoID, I was written by Dern Jordan, who's my colleague, he actually works on another team, and he doesn't work on MongoID anymore. He left it to me, and I've been trying to make it better. It follows this philosophy that it should be as close to Active Record as possible, even though, fundamentally, MongoDB is very different from a relational database. I'm stuck in between designing if I should push MongoD in a direction that makes it distinctively different from Active Record and really braces a lot of the characteristics and exposes a lot of the characteristics of MongoDB, or if it should stick with what it has been doing up until now, is mimicking Active Record as closely as possible, and sometimes, in some cases, abstracting things from, and keeping the user from knowing exactly what's going on in the OVM object document method itself, and thus not realizing when they might not be doing something the most efficiently. So, that was a long context, but I'm not really sure what questions are going to be asked, but I wanted to, I'm taking notes. If you want to email me later, today I did a video call with someone for two hours, who's a pretty active MongoD user, and I just wanted him to tell me how he felt about MongoD and what direction he wanted to go in. I'm going to say that after my talk. Actually, a keynote is, if anybody is open to doing that, it would help me so much, because I don't really know how to get these opinions from people, and if you want to just come up to me during the conference, are you all going to the conference? Hopefully, yeah. If you want to talk to me at like, better on, I'm really open to hearing everybody's opinions, so you can just like, start now. Raise your hand, tell me what you think of MongoDB. Does anybody use MongoDB here? Raise your hand. MongoDB, so you use MongoDB because you're using browsers. Okay, so it's not as amazing as I hoped, but... So I asked a few people around earlier, they were like, why MongoDB? And then one guy, he raised that OSPRESS has JSON support now. So that reduces the need for Mongo, perceived need for Mongo quite a bit. So from your standpoint, why Mongo? Why should they look into MongoDB? Well, so, okay, I'm not so familiar with OSPRESS, but they basically just have this one... JSON conference. JSON into a... Yeah, you can search the keys and stuff. Can you index the keys? Yes. The keys of the... I think it's definitely kind of embedded. I don't have that on the company. Okay, so that's a very simple implementation of like, saving a document. So MongoDB has so many, it's really rich in features for how you can deal with documents. You can index embedded documents. You can index keys inside keys, inside documents inside keys. You can have arrays. Can you have arrays in a JSON thing in OSPRESS? Okay. You can... Can you do aggregations or search across? Okay, so MongoDB is an aggregation framework, which is like a really rich way of acquiring the data. So we're trying to provide a feature that makes it so people don't necessarily have to do it before. We also do that for OSPRESS, but it's kind of deprecated. We're focusing now on that aggregation framework. We have a really rich acquiring language. We have... Like, so... Anyway, I'll stop there. But to answer your question, that's kind of like... I understand from Postgres, it's quite a view that's... responding to a certain need that people have, but it's very simple, compared to what MongoDB has. It's not just a simple document. Okay. So anyone has any questions? Yes. Yes, I have a question. I don't get it. Okay. Yeah, that's not a question. Yes. The data island makes Postgres often relational in some shape or form. Anyway. That's right. I just don't get why... What is the game? Okay. I mean, that's... I'm not saying everybody should use MongoDB. I'm just curious if... Like, that's fine. I totally agree that there's some data that is relational, inherently relational. And you... Why would you use another tool? Right. Everything's working out so far. So what are the things that it's good for then? I mean, what would be something that really shines? Okay. Who uses MongoDB again? What do you use it for? Why is it good for your use case? So in my use case, they were using MongoDB for actual documents. So they were kind of mapping a workflow at an office or a certain department. And then they switched to MySQL. And it doesn't make sense. They should have started with MongoDB. Okay. They thought it's... And that's probably what we should talk about. They have their mobile thing. They didn't get it. So they kind of got confused with the mobile. Yeah. Instead of thinking in document, they switched to MySQL, which was a mistake in my opinion. Right. In that particular use case. Okay. So the friction there was more that MongoDB can expose the behavior of MongoDB enough. So that they were too far from what's actually going on. So then we didn't really know that... The thing is... Did you think it would have stuck with MongoDB if MongoDB was more like document-y and not relational-y? So the thing was, we had this... We had documents. And those documents had envelopes. Like, you know, we kind of tried to model a physical, high-end exchange product. When I bring in five files to you, you send them and put some copies. So it's basically perfect for MongoDB, in my opinion. I have no idea about MongoDB to be honest with you. It's not more logical to use a document, a database for documents. And then they used MongoDB on top and tried to make it relational. And this is kind of where I am kind of insane. Like... Confusion. Confusion. There was a figure that I didn't understand because documents are going to be relational stuff, post-quest, or whatever. And they were kind of doing MongoDB without thinking in a document-based mindset. And that's kind of... This is the thing, where I also took use with other programs. I've seen some things, I've seen a virtual active record on MongoDB with other relationships and so on. People usually take an approach and they try to build a relational database out of MongoDB. So I think the real problem here is to focus what MongoDB is good for. Right. And that's a problem that most people follow up in there. Yeah. That's the thing, like I... philosophically, with MongoDB, I would love to make it more of a MongoDB flavor, but at the same time, I'm afraid that that would alienate a lot of users and also make the transition from a relational database so going further would just be way too high. I'm not going to do the problem. I think the relational model is doing better than our mind's knowledge. And we try to wrap MongoDB and make it a relational database. Yeah. Do you think if I made an ODIM that was not active record, like maybe the variant entry would be bigger or more difficult, but then once you're there, you get it? Or is that... So the examples in a proper use case is where the document-based approach fits in better would be great. Like something complex example, how do I use MongoDB properly? So we understand, okay, this is actually what I'm looking for. Okay. Instead of trying to, you know, this is like a blog post, and you have a blog, and I can have a blog post and all this kind of stuff. Okay. So you asked me to do that right now, or do you think that... Do you think if I like provided a sample app that everybody knew about, that showed a really good, really interesting branch example of how it can be used well, would that be useful? Because I know like blog posts. Maybe so. With recipes where you can... I mean I'm saying this and I should write this for my own stuff as well. You mean I write a good book of like different apps. So a good book, you know, we show like, for example, the kit we have with the files in the end of all this kind of stuff, and then just quickly, like some diagram, I always work with people. So people get the idea of document-based development, because I don't get it. Okay. Well, I don't know everybody's the one that MongoDB has. And we're all like, MongoDB? Yeah. MongoDB. EDU, is that what it is? MongoDB University. And we have these amazing courses and they're so popular that we hire people who have done really well at the university. So if you're... I've not taken these courses. Obviously. But we have, so we have basic diagnostics and debugging, performance in .NET, in Node.js, in... I can also... I saw it somewhere. Oh, I'm not sure. Well, actually, hang on for a minute. Let me just... Let me just close my... Okay. Okay. So this is MongoDB University. If you're... I recommend this as a resource. I'm not... I'm an engineer, so I'm not very good at the sales part of MongoDB, if you can probably tell. But I know we have a lot of resources for people who are curious about it and also people who are knowledgeable about it, so all this stuff. So if you want to check it out and I think the features of the database make you understand more why people want to use it. So I've actually used MongoDB University before and a lot of it was more operational and how do you do this, how do you do that? I wasn't much on how do you architect the data structures to fit MongoDB's use versus those rest of my experience. I'm sure if you're on how would you... How would you structure the data structures within MongoDB as compared to the traditionalization of the database? Okay. These are the logical examples. So I think one of the main... When I first started my movie five years ago, we were a very small company with like 50 or 60 people and there were like 700 or 750. So engineers did everything and I did a lot of presentations on schema design. One of the things I would say over and over again, this is five years ago also so obviously the database has grown up a lot in the last five years is that what's different about MongoDB you're talking about schema and the structure, yeah. So what's different about modeling your data with MongoDB is your data is modeled in the database much more closely to how it's actually presented or used in your application. So this is an oversimplified example also but if you were building an app that was a bookstore like Amazon or something and every book you showed in your app or used, worked with in your app always had the author information or just like the author information you would maybe put the author information as a embedded document inside the book document so that when you loaded a page all of the information you needed on one page could potentially be served by one database required because we don't have joints. So when you think about your schema with MongoDB you think more about your usage of the data what is going to change what isn't going to change so like a book's authors the author always isn't going to change the name isn't going to change the person, they have a certain birthday and so things that don't change like that they're safe to be embedded documents inside a book and then maybe have the author document be represented as well in another collection but you have maybe some duplication and that's okay because when you get the advantage just like a minuscule amount of duplication and the advantage is that you reduce your database queries and you can index on these embedded documents as well so as a general, it's hard to talk about it without a lot of examples but I know in general the mindset is a little different because you have to be a little more comfortable with your data not being so perfectly square all over the place kind of like push things together and mold the representation of the data to be more closely related and basically representative of how you actually use that data and it's uncomfortable for people who have been working with relational databases for so long you're so used to favoring data integrity or like you think it's very much transaction more advantage yeah, yeah that's it so the point of the moment if you have a schema structure you have redundancy like you want to have this like if your example said when the author's birthday or something it's not going to change so you want that redundancy just in case the author has two books and you would have an author copy or just a reference I wouldn't say that the approach itself or the goal itself is to have redundancy when I'm saying if redundancy has a wide effect of maybe modeling your data in this way that's usually okay or that's something that you can do and make work for your application so if you have author information repeated on book documents you could also have like a callback on the author that if the author changes you could like update it or something but like how often does the author data change, like whose name changes so if it was to change let's say I had married and my last name changes and I had like 15 books would I have to go through all the books like is there like a normal to be API to change that or how do you model that yeah you could I mean there's you can do an update on books like you could say update operation takes a query to see how to get so you could have a query in your books collection where author any mentions x or author name matches x updates it to y so you can do update any it's like we have pride just like how does Mongroyd do that because I think Mongroyd will say book has one author or something like that if I update the books Mongroyd will say that the query you were just describing so next book where author name goes blah blah blah and update name so first one question are you going to the red dot movie column yes so I'm talking about this in my which topics you'll see exactly how all the relations work in Mongroyd but I kind of kind of have relations one is reference and one is embedded reference functions exactly like my school or relational relationships where there's a foreign key saved on documents and it has had many belongs to hasn't belongs to many has one is it and then the embedded relations are embeds many and then and then sick with embedded which is like you have a tree just keeps going so to answer your question how Mongroyd would handle that relationship and update the documents depends on how you define the relationship if it's book in this case would be has belongs to many because a book could have many authors and an author could have many books and then in that case both sides save an array of IDs and there's no joint table that's actually this difference so there's no joint table the book keeps an array of IDs so that's by reference and then that's in a minute and then authors have a list of IDs and books I already know the fields yes no so what what it sounds like you say is that that lends itself to a scenario where you have a massive overrepresentation of reads because in a hypothetical case where Nick gets married and changes his family name that happens once but that book gets presented like millions of times a day so that's why you don't want to have to do that additional table to look up which affects the author name is that what it is? I'm not sure I understood the question so you're saying if he updates his name he changes his name and that happens very very well and you don't care about the fact that you have to go through additional books in order to update it everywhere else because this stuff is being read so many more times than it's being written so that's why you want to have that advantage of keeping all the data together into one query so that's what it's good for these very read heavy use cases or you can think about it as data that is immutable like quasi-immutable is a good idea not to say not that everything that's immutable should be immutable so if it is, it's a strong enemy you definitely don't want to do that if you're going to substitute it very often I'll just share another use case for long term TV so we use that at our company it's an improvised product so very briefly the model would be something like a venue, as many devices the device has many locations the interesting thing is we found that in that specific use case won't be me suited our model because all the locations will come together within a certain time frame for example we need one hour there's no point getting one location in that 30 minutes and linking it with something else data that comes coupled together it actually makes sense to put it into a nested document model because then you don't have to do any joins and you just take a chunk of data and then it's all there and you can do whatever you want to do and that made more sense for us in that use case when we had to do aggregation so if you imagine a document it's just a record it has readings, locations every 5 seconds for let's say 15 minutes and we have to do what you call a slice and dice analytics like every I don't know every 30 minutes or something like that then MongoDB's aggregation framework made it very easy for us to go free and do the in database aggregation for free so that's maybe not the same as the data modeling but the aggregation comes free with it in that case it saves us a lot of time in modeling because we actually didn't know how we were going to analyze it later from just put data that should belong together in the same place and then it could just go together and get updated together that kind of thing that's a good point I don't think I made very strongly either is that your schema is flexible so you don't have vibrations if you want to add a field to a document you can just add it and you can check if that field exists in the document in your query so you're not going to like you can you have a rich query language if you add these fields you can also select documents that don't have a skill or do have a skill and that's I think a big advantage for people as they're developing especially with agile development practices because you don't have to know everything and you can adapt your application as you work on it and that functionality actually helps a lot with big data so I was in a start-up that converted big data to PowerPoint slides so it took whatever type of data from people to other type of agencies and Google and all that and at Google like one one you'd be like oh we have this new key right and then the next one you get all these keys so that allows you to update really fast on the site so that was really good for keyboard development and the fact it was document based allowed us to shut much earlier as compared to it was pre-national based right so if it was pre-national based we would now be figuring out how to do the drawings across multiple data bases outside because MongoDB provided that Mongo S layer that they want to shut things down for us automatically although we still kind of know what happened yeah like when you said that did you start with MongoDB or did you start with the relational database and transition to MongoDB because I'm not a keyboard so from my understanding I joined the company after they've already used MongoDB and I found that it's good fit for the data model I'm not sure if they started with something else but when I looked at the analytics that they were trying to know it kind of fit quite well because it made the conceptual understanding very easy so if I were to say what if I were to imagine implementing these functionalities in a relational database then the red flag would be a lot a lot of drawings but the rule is not just relation of the MongoDB that was true so once it sounds like if the schema is dynamic I haven't figured out if MongoDB may be good I don't know if it may be good so after I figured it out does it mean I transition to a relational database or a time series database or I got this it's not to be like that in our case it's actually people more it actually became actual documents start in page base in our big data data store where we had to scale larger but that is if we actually wanted to run very large applications over a very long period of time which comes back to one of the things I wanted to ask applications around the aggregation framework and the document size I guess that's a good reason for performance so to us we actually found that there was a certain point when the data became very large or very complex that aggregation framework kind of didn't really meet our needs it was timing out and stuff like that do you mean the result size or the size the temporary document I don't remember the limit is for that exactly but I'm sure it's getting bigger that's fine because at that point we had the luxury to then figure out what we needed we tried to wake up the king power of talk with the ETM and stuff like that but it's fine it means a proper service what it was good for what we were able to do and then we moved on to something else I think we can also now I think where you can split off in the middle of your aggregation and are you on the latest version okay because I think it's great for you to use something like that to help you but even when you split the whole thing it's just point memory you can output to a question okay anything return it personally or else I have a comment sure to me it sounds like more and more interesting than the last 20 years so it sounds like it's a really good deal so I think is I use a relational postgres with jcmd columns and I think because I kind of need some little bit of my relational stuff I actually enjoy that and I think how to read it later but that's basically what normally it kind of seems to be way better as compared to postgres but here's the problem you were asking why is it not popular in movie the problem is we all come from rails and we think in database tables because the database table is our model and that's what is good for the code and that doesn't fit with the thinking not at all because the model thinking is more like here's a document checking some stuff and here are my objects that work with that document that doesn't work with the traditional rails way of thinking so that's kind of where you have the area you have to play because people in rails are obsessed with models equal database table I'm also trying to fight this thinking but that's the problem use it away that's kind of creating a problem question that's exactly why I'm sitting here with this microphone in my hand yes that's my stay up late at night thinking about this the same question is it ever a valid use case to have both postgres or any other version of database together with Mongo? I think I've heard of people doing that I think in a rails application you can have different databases different purposes one of my good friends in Berlin I know his application does that if I don't necessarily think that Mongo will determine whether the answer to that question or no I think it's more like what your use case is if you find that you have some very specific area of your application that is really good for MongoDB or MongoDB is really good for it and something else that definitely needs to be relational then that works for you then I think it's totally possible I've heard of people doing that so at the previous company I was at all our big data stuff was in MongoDB whereas all client data was in postgres itself so it's perfectly normal to have it because it was used for the right of postgres that should be our Mongo position it should be the radius in the rails not the active I cannot move my user position companies belong to many I'm not going to do that relationship data which pose back to your first point should Mongo continue that active record think of those sorry for everybody here probably one of the first 5 tables that you create is like user and just don't see how that's not traditional I mean it's possible that you have a user model or user data it's not traditional to other users or even something like blog posts or movies but whatever primary has many things that user has traditional I'm trying to compare it with Redis Redis the logical things that first use it for things like delay job or something like a cache but for Mongo I was in mom's position I would try to post it in such a way that you can use Mongo for this but you have to keep your national data and it starts off thinking of any user object or I don't know whatever I have a question if you have a user object with a relational name and you have phone numbers for that user do you save them in another table how do you save phone numbers at the start for me I try to just button the table itself and it expands because you can't have an array so you just have phone number one, phone number two I'm not sure for other people but I guess for at that very very start you start off with just one I think that you should use it when you phone number or something like that or you can use it to do something because when I think of a user I think for me I've been thinking in MongoDB for so long it's a very natural thing for me but I think a user in MongoDB makes so much more sense to me because you can just have an array of phone numbers or an array of documents that are addresses because how many of us only have one address we have shipping address home address for me it's just you have this rich document because you don't want to have a table of addresses where it's just because you're the only one living there usually I mean but so if I understand what you're saying though you think that that there might be it might be interesting to think of a strong default use case for MongoDB so when people think like that they think it becomes the obvious MongoDB becomes the obvious choice for this type of model because of what you're doing what it sounds like you're saying is that some of the objects we think about when we're using Rails are already representative relationally so we need to think of relational database like the mindset in all of the examples is relational actually when you're speaking I thought that yeah it doesn't make sense I'm not sure with this but I think if you ask the programmers some would make the address like the field like city, country, whatever for a user or they may make it like a JSON capture or they may make it into another table normalize it so I guess for just thinking of that I have zero experience with MongoDB but if it was probably in MongoDB's position and wanted to position it in such a way that it would make things probably just there is people that instead of thinking what to do we have these solutions that work better that makes sense but I guess the reason of all the people for this is using a relational database then maybe add MongoDB at some point yeah I think that was the thing that was getting to you about that cookbook right wait, were you saying creating an app that's a cookbook or creating a cookbook that's kind of like a resource this is the problem these are three solutions the phone numbers that make people understand the natural organic way of MongoDB that's a big idea so if you want to see more MongoDB like objects you can try a 4 square API I'm not sure if they use Mongo but they have JSON objects too yeah they they use it I like how close they are yeah can you show some quick example of how to use Mongo without MongoDB in Ruby like with the driver maybe just the gift out read me or something so we can see some like close sure I don't understand how you're accessing it okay so this is the so you want to see how to work with okay this is the driver yeah so this is the driver there are no models here it's just really hashes and then operations on the database okay so the driver so there's like the Ruby project or the Ruby offering of MongoDB is three parts there's MongoDB which we talked about a lot the driver and then BISAN BISAN is a gem that just does the serialization of hashes to the BISAN data type then the driver is in the middle of the abstraction of MongoDB and BISAN gem so what I'm doing what I'm using now is the client it's kind of like a connection object in ActiveRecord so it's pure operations to database and the the only objects I work with are hashes and the hashes represent it's a one to one mapping basically hashes to MongoDB documents so I'm going to create a client this is the client it's debugging that it connected to a single server part of one of the major parts of the responsibility of the driver which makes the code a bit opaque and complex is that with MongoDB we have replica sets and charted clusters replica sets are what they sound like it's where you have a single primary node server and secondaries that replicate from that primary automatically and you set this up now many ways to set it up but you can set it up manually and the client's job is to keep track of what servers are in the replica set and this case they only have one envelope that's why it says topology type changes tables but if you have a replica set all these messages will be more descriptive in that I'll say they've discovered this server it's a secondary this server it's a primary and then we have just down a secondary stepping you'll see that all allowed by the client so then if I want to the client object is as I said a connection to the database in this case I'm only talking to a single node a standalone and the client has a connection to a single database at a time so right now it's connected to admin by default but I can say a new client say test so now I had to create it so now I'm connected to another database called test and then this syntax for accessing a collection it's like this oh it says collection so that's a collection so now we have this collection object I'll insert a document and it's really simple you can see through the hash so let's do like a bridge this is a hash and I'm saying insert one and you'll see the operation it does an insert into the test database into the test collection and then this is the document study inserts so I can do an insert one I can do an insert many and then I'll provide an array my brother insert many the first the first the array I did yes okay okay so and then the result is so you can get like inserted IDs for example this is the result or object so it's a whole frame what else do you want to know do you want to know how do you write last minute okay so client test collection let's say let's say my brother gets married wait no this is last minute to change um my brother decides to change his name to David so I'm going to do update one where first name is David that's the query and then I'm going to set and tell me if this looks wrong or something test update one so I'm going to query for all instances well just one instance first instance that the first name is David and then set the first name to Dave okay so that I just did an update um you can see the update here that's the operation the test database update operation the test collection the query was first name David it updated to set the first name to Dave that's the case of all sets because I'm using the update one method as opposed to update many which would update all of the documents that have um that um so now I can just look at my documents so now you'll see my first name is Dave and then update many I can say last name stopo and let's change it to before we came to Ellis Island it's actually stopo let's set up yeah so now all of us will be stopo so anything else you want to see how do you query the stopo family now with the connection how do you query the last name because it looks quite fine so the yeah it would be last name we basically have a new collection to find with the driver oh we have all crud um like uh can you see it uh can you try it for yourself oh wow I didn't know what for this well that's not really possible um okay okay stopo um um okay okay um we have all crud I can show you our docs we have like we have aggregation framework we have grid assess which is a way of saving large files because the MongoDB document max size is 16 megabytes but if you have files that are larger than that has anyone used grid assess so it's a it's actually not a feature of MongoDB it's a feature of the driver but it's a um it's a yeah it's a methodology for how we save files so that we can spread them across multiple documents um group them back together to sort of file so that's MongoDB um that's like those two drivers you can see the documentation here the client they're like a million options to send to the client that have to do with everything like how you monitor your rubble kit set or your um with SSL writes and everything um so for an operation there's anything that you would expect we added a decimal 128 type recently um which is high precision representation collections um aggregation framework we've mentioned a few times it's based on this idea of a pipeline um which is like a unix pipe conceptually in that you the way you construct your aggregation pipeline is by thinking about each document being tapped into it one at a time and they get manipulated by the queries and operations that you do in your in your aggregation so you can match and then the next step in the pipeline will only be applied to those segments and have to match for example um group and um I think it's it's really powerful and people really like it and um we're trying to push people up not produced because not produced is a implementable JavaScript so it singles that in really slow whereas aggregation framework is uh an implement in C++ which is the language that the server is implementing in so it can be much more we have both operations so you can send a mixture of operations all at once that's one single request to the server I don't know if people use that that much though it's kind of um I think it has specific use cases if you're really interested in higher end performance but for most applications it's not so useful or people don't use it so much and then we have text search um with collation support in the last version um where you can have collations for indexes as well as for your searches it's really important to have for our um for the global use of how many needs um pretty fast is what I mentioned oh we have geospecial search which is something people really like as well it's really useful I think as as a feature of your database so that you don't have to have a separate service in order to use geospecial searching so pretty fast is the file um oh yeah yeah yeah cat collection is a cat collection it's a collection of a fixed size and um as you insert data into it once the region is like my size it looks around insert so it's um it has some use cases like we actually use it internally for the off-log so if you have a replica set the members of the replica set have a cat collection that states all of the rights that they um that they're recording for the primary appliance themselves like a time-safe database that they yeah if you're familiar with um I think reefing has something like that um yeah yeah or if I'm telling the what is the the reason for files in the sandwich yeah um if you have 16 megabytes 16 um so if you have a file that's larger than that that you like to save in the database it's um it's a convention that's sort of a convention that all the drivers influence for saving files so that um you can save data that's larger than 16 megabytes um so you can have the filing to the file on you and then perhaps the real file how does it work yeah so we like when we first wrote the driver it's probably too much detail but we kind of have like issue APIs for the print-up best but there's one that's favored that is the official API and it works on this idea of stream so you would open an upload stream like this and give it a file name and then you would write the file like this this is the preferred API but when we originally released the drivers um like rewrote it with Jordan like two or three years ago we didn't have the convention documented across all drivers so we just kind of implemented grid of best how we thought it should be implemented but then the driver sees back together and wrote specifications for how it works that's why we have kind of two APIs um but the favorite one is uh the one that includes streams you would open this upload stream and then write to it and then um this is how you would download the file so you would normally kind of know like create this user with phone numbers and then for example upload the password something in a separate operation because here you got the example of the shell we have this um new insert because there's like two different API grid of best APIs is not integrated with insert API or grid of best uses the insert API internally so I could insert everything in one no phone number and also the password not in a state operation if you're including a file you could have us if you're just exactly what you use but normally you'd be going from one way anyway so mom you look like not really but not necessarily but if you're working with these objects you probably wouldn't have would work with them because I've tried to find a simple way for small files and I don't want to use Amazon it's not like 64 megabytes it's just about a couple of megabytes so this looks like a convenient way to convert the photo into a binary string and store it in something grid of best has go into the document the user document there's a new type called binary these are the types so we have a binary which is binary data I don't have a visa but there are different types for the binary this is the this is a visa job I'm mentioning so these are the types for the binary can I answer your question? I think we're at a time right? I think it's good there's a lot of interest so maybe one direction might be the advocacy but in terms of books, examples even potentially workshops because my own biased experience was that when I started looking at MoDB I really had to question how I want to design my schema what to agree and what to refer previously in my limited experience with a relational databases it's mostly just foreign keys and deaf joins but this may make things a lot more actually like that in the experience this is really helpful and if anybody wants to email me just give me more information it's really helpful for me and if you want to do a video chat like I did today it's really a huge source of information for me it's really useful so otherwise I'm just ready to go in a vacuum thank you