Log file Viewer

[09:57:59] <techie28> how to get writeresult's properties after db.collection update execution?.. have defined a callback in update with params err,numberAffected,rawResponse but I dont see nModified,nUpserted etc in any of them

[09:58:05] <techie28> any ideas please?

[10:48:49] <techie28> nRemoved,nInserted properties are set only if anything was inserted or removed in the WriteResult callback?

[10:53:10] <davesleep> do mongo exist as a database as mysql does?

[10:53:19] <davesleep> it seems stuff just gets written to it at it accepts it

[12:25:15] <xananax> Hello; Is there a way to store my database under in my nodejs's app directory? I'm prototyping and being able to save the different databases models under their respective directories would help

[12:25:47] <xananax> I'd like to have ~/projects/apptest1/db, ~/projects/apptest2/db, ~/projects/apptest3/db...

[12:26:17] <xananax> Is it possible? Sorta like meteor does it

[12:49:43] <techie28> how to access the MongoDB Write Result properties after an update in Node JS?

[12:50:07] <techie28> I want to send the number or updated/inserted docs back in response.

[14:26:06] <nixstt> I have 2 replica set members and 1 arbiter, the replica slave is stuck on recovering (probably cause of insuficient oplog size?) how do I change the oplog size safely?

[15:02:36] <jasonfx> Hi, if I do .find() on a collection are the documents returned in order of insertion? Or do I have to do a sort?

[15:04:45] <vhf> jasonfx: you have to do a sort

[15:05:20] <jasonfx> vhf: thanks, that explains it! :)

[18:51:54] <tejasmanohar> should i hold a counter_cache in mongo?

[18:52:04] <cheeser> a what now?

[18:53:42] <tejasmanohar> cheeser: say i have a bunch of Tickets that belong to a User and i want to Ticket.count({user: ObjectId(of a user) }) a lot

[18:53:58] <tejasmanohar> would it be wise to keep another field like ticketsCount on the user and keep that up-to-date instead?

[18:54:23] <cheeser> that's an option. you'd just have to make sure it's always updated.

[18:54:31] <tejasmanohar> kinda like a rails counter_cache http://guides.rubyonrails.org/association_basics.html

[18:54:32] <cheeser> depending on the amount of data, a count could work just fine, too.

[18:54:42] <tejasmanohar> someone was telling me thats less necessary since mongodb indexing vs like postgresql

[18:54:52] <tejasmanohar> is this a valid point? if so, could you expand a bit more on it?

[18:55:07] <cheeser> i don't know what that pgsql comment is even supposed to mean

[18:55:23] <tejasmanohar> yeah me neither so im asking

[18:55:58] <tejasmanohar> MongoDB uses a simple paged memory management system is what i read

[18:56:02] <tejasmanohar> so a counter cache isnt necessary

[18:56:46] <tejasmanohar> cheeser: at what # count do you think running count() would not be worth it?

[18:56:53] <cheeser> that depends. the default in 3.0 is mmapv1. in 3.2 it will be wiredtiger. so the memory profile can look very different depending on your storage engine

[18:57:12] <cheeser> it's less of a count and more of a speed thing. how fast that count happens can vary based on load.

[18:57:22] <tejasmanohar> alright

[21:45:24] <bjorn`> Moin

[21:45:30] <bjorn`> Quick q; I'm deploying mongo on flash storage (SD/MMC cards, embedded hardware) for a data harvesting tool. Is there a way to limit the number of disk writes in mongo to, say, twice per minute, to increase the lifespan of the SD card?

[21:47:44] <cheeser> there's a sync setting iirc

[21:48:46] <cheeser> syncPeriodSecs maybe

[21:49:17] <cheeser> http://docs.mongodb.org/manual/reference/configuration-options/#storage.syncPeriodSecs

[21:50:15] <bjorn`> so it's 60 by default

[21:50:36] <cheeser> unless overridden by a WriteConcern

[21:51:05] <bjorn`> "If you set storage.syncPeriodSecs to 0, MongoDB will not sync the memory mapped files to disk."

[21:51:20] <bjorn`> Maybe I should set to 0 and manually fsync using a cron job every 5 minutes or so

[21:51:42] <cheeser> that's a lot of tolerane to data loss...

[21:51:53] <erenburakalic> bjorn what is the advantage of that?

[21:53:12] <cheeser> there's also this to consider: http://docs.mongodb.org/manual/reference/configuration-options/#storage.mmapv1.journal.commitIntervalMs

[21:54:18] <bjorn`> It's going to store long term data, 5 minutes of lost data isn't going to be an issue. I find the long-term reliability of the SD card to be much more important

[21:55:03] <cheeser> an SD card probably isn't the best choice...

[21:56:01] <bjorn`> It's far from optimal, no

[21:56:56] <StephenLynx> is mongo really the best tool for that case?

[21:57:34] <bjorn`> That's a valid point; there might be better options - I'm open to suggestions. I just defaulted to mongo because that's what I'm used to

[22:00:13] <StephenLynx> sqlite, plain text files.

[22:00:51] <StephenLynx> mongo is not designed for low-capacity machines.

[22:00:58] <StephenLynx> like embedded ones.