[01:09:29] <FuzzySockets> Boomtime: ah, here we go... thanks :)
[01:09:39] <Boomtime> if you are using mongoimport i think it accepts either of those formats - but the strict mode is "proper" JSON
[02:55:11] <FuzzySockets> Anyone know where in the docs I'd find information on importing json files to collections through a javascript file? I read the part on executing scripts, but I can't find which function I'd call to import json.
[02:58:53] <FuzzySockets> meh, I'm just going to write a bash script
[03:04:21] <FuzzySockets> Boomtime: But I'm using the page you just sent in a bash script instead, much easier.
[03:04:57] <Boomtime> right, well bash can't obviously speak to mongodb natively, you're gonna have to call something - and that something is mongoimport
[03:05:17] <FuzzySockets> Boomtime: I was asking how to read in some external json in a file called say, seed.js, and import that into mongo, from within the javascript file.
[03:05:32] <FuzzySockets> Boomtime: That's what I'm doing. A shell script with mongoimport commands.
[03:07:09] <Boomtime> goodo, so you're all good now?
[03:07:19] <FuzzySockets> Yeah, this seems to work. Thanks :)
[08:21:21] <Desetude> I'm currently looking for an asynchronous mongo object mapper
[08:22:02] <Desetude> So bassicly, it will create a dummy object which will be returned with default values and then when the values have been found on the db, the values then are set
[08:22:25] <Desetude> Anyone know an object mapper which can do something like that?
[08:32:29] <kurushiyama> Hi. Anybody can give me a link to an automatic data modeller?
[10:22:30] <zsoc> Is there a way to push onto an empty array when I'm already pushing into a new subdocument? Like can I { $push: { subdocuments: { sub1: data, $push: { subarray: data } } } }
[10:24:23] <kurushiyama> zsoc: why do you want to push? simply use ... {sub1:data,subarray:[data]}
[10:24:49] <zsoc> ofc it's empty, i'm just creating the subdoc lolol
[10:25:10] <zsoc> Sorry about the enter spam. Thank you kind sir.
[10:25:23] <kurushiyama> And that is one of the many reasons why I think that too much embedding is the root of all evil.
[10:26:53] <zsoc> I am brand spanking new to node/front-end anything/jade/mongodb/mongoose so i'm tasting a little of everything. Every other model/collection in my app are completely (or almost) flat..ish, and hold a reference field... just this 1 thing I am embedding because I am trying to figure out if it's ever useful. Out of all of my data this is the one thing that seems like it makes sense, so it's a learning experience.
[10:27:25] <zsoc> mongo so far has been an interesting experience.. it's very anti-db.
[10:27:27] <kurushiyama> You sure what Mongoose makes of it? ;)
[10:27:48] <zsoc> Oh right, this channel is anti mongoose ya?
[10:28:01] <kurushiyama> Here is my suggestestion, _especially_ valid if you learn. Use the raw driver. model manually.
[10:28:14] <kurushiyama> For various reasons, yes.
[10:28:25] <zsoc> I'm learning all the syntax along the way. It seems like there have been many syntactical changes over the last few years, both in the driver and mongoose
[10:28:56] <kurushiyama> I for my part think it is wrong to make the devs think in SQLish terms and basically force them to model accordingly.
[10:29:36] <zsoc> I don't feel like there's much sql going on here... I mean to me it still feels like I'm interfacing with a giant JSON object but requesting it do things nicely. I mean I guess in theory that's what mongo is anyway
[10:29:52] <kurushiyama> Define your use cases, derive the question your data needs to answer, model optimized for the most important use cases.
[10:30:15] <zsoc> how do you find mongoose limiting in that way?
[10:30:17] <kurushiyama> Following this approach, Mongoose has little to not advantage.
[10:30:50] <kurushiyama> Except adding a layer which reduces performance for no good reason.
[10:33:17] <zsoc> I sort of was digging the schema angle... it keeps me organized I guess. Everything is so abstracted out here in javascript land it almost feels more natural to /not/ user a driver lol
[10:33:53] <kurushiyama> If you do use case optimized modelling and prevent .populate() (which you should), what advantage does Mongoose have? Except coercing you into its syntax, abstracting away this and that advantage of MongoDB. The schema angle... Well, think in BSON docs ;)
[10:34:53] <zsoc> I mean as it is it wouldn't take much to strip it away.. and I might. I don't forsee this project approaching anything that would show performance issues really...
[10:35:09] <kurushiyama> zsoc: Really, learn MongoDB raw. You will learn a lot. If you till feel like using Mongoose (I doubt you will), you still can use it. You would not use an ORM without understanding SQL properly, would you?
[10:35:16] <zsoc> There's other stuff out there too, I dunno if any of them have taken much hold. Mongorito seems to have a following.
[10:37:10] <kurushiyama> zsoc: Back to the drawing board, then ;)
[10:39:12] <zsoc> So ... I mean what's the alternative. With the native driver do you just pass the db to all routers as middleware? That just seems a bit 'global'-ly to me.
[10:41:23] <kurushiyama> zsoc: But makes sense. The driver maintains a connection pool, if I am not mistaken. At least most other drivers do. ;)
[10:42:27] <zsoc> Hm. Alright, I mean I guess it does make sense. There's __v and whatnot to make sure everything is in place.
[10:44:16] <kurushiyama> zsoc: Sort of. __v is supposed to be for optimistic locking, right? I saw update queries from mongoose ignoring it. Question remains: what is it good for, then?
[10:45:21] <kurushiyama> zsoc: And implementing optimistic locking yourself should be rather easy: query for the document as it was. If none is found, you had a concurrent update.
[10:47:36] <kurushiyama> Or implement a field for optimistic locking yourself. Many ways to do it. With an ISODate field, you can even have retetion times and what not ;)
[10:50:38] <kurushiyama> zsoc: Note that my arguments are only about the concept. Several people additionally have more technical concerns – which I can not agree or disagree with, as I only played with node and Mongoose.
[10:51:38] <kurushiyama> zsoc: One of the major problems I have with Mongoose is that if you are not _very_ careful and know what you are doing, you might come up with a datamodel which does not scale (read "shard") well.
[10:52:43] <zsoc> in fact that seems to be a major complain about mongo in general.. but it appeared to me as just poor modeling
[10:53:56] <kurushiyama> zsoc: You are right with that. Most clickbait blogposts about MongoDB not scaling well or "loosing" data can be dissected to poor data modelling, lack of willingness to read the basic documentation and outright ignorance.
[10:55:04] <kurushiyama> It is not that MongoDB is perfect – I have had my issues, as most people likely had – but most of them were either immanent to the technology or were my fault.
[12:50:31] <scruz> what am i doing wrong in my $group? http://hastebin.com/evapobazik.sm
[12:51:18] <scruz> i need to get the counts of docs marked verified and docs marked flagged
[12:59:05] <scruz> the $group is the last (and only nonworking) stage in my pipeline.
[13:13:58] <scruz> i need to count two properties on my docs using an aggregation pipeline, so i’m using $group with $sum and $cond, but i’m getting the error ‘Invalid operator’ on aggregation
[13:14:18] <scruz> here’s the $group stage: http://hastebin.com/evapobazik.sm
[13:32:07] <scruz> never mind. instead of letting each doc be flagged with true or false, i flagged them with 1 instead and summed the fields.
[13:32:07] <scruz> *flagged them with 1 or 0 instead
[17:34:51] <diegoaguilar> In mongo 3, can I search in some collection and get the count based on the results _ids of refs in another collection
[17:35:53] <diegoaguilar> the use case is, list some products, and get the count of them in the items collection