[05:53:10] <sgo11> newbie here. The official doc says "apps may observe 2 classes of behaviors: 1) mongod will allow clients to read the results of a write operation before the write operation returns. 2) If mongod terminates before the journal commits, even if a write returns successfully, queries may have read data that will not exist after the mongod restarts. what are the differences btw the two classes?
[06:02:49] <Boomtime> sgo11: the first point is merely saying that other clients may see the result of a write (due to reading a result set which contains it) before the client which wrote it gets a response
[06:04:14] <Boomtime> sgo11: the second point is more subtle, it is possible, though unlikely, for a client to read data which has not been made durable yet
[06:04:40] <Boomtime> the promise of durability of data is made to the writer only, not to readers
[06:16:17] <sgo11> Boomtime, thanks. I am a newbie. I don't understand the first point. For the first point, does it mean mongod applied the change to in-memory data and clients read the new in-memory data before the written client gets the successful write response from mongod?
[06:19:13] <Boomtime> sgo11: the first point is possible in many conditions, even discounting in-memory changes
[06:19:29] <Boomtime> once a change has been made, a response needs to be sent to the writer that it was successful
[06:19:57] <Boomtime> mongodb cannot possibly guarantee this response is received by the writer before some other reader comes along and reads it
[06:20:06] <sgo11> Boomtime, if in-memory doesn't change, how can a clients read the modified result?
[06:20:52] <Boomtime> the changes are made in-memory first, but that isn't the reason a readert can see them first
[06:21:11] <Boomtime> "mongodb cannot possibly guarantee this response is received by the writer before some other reader comes along and reads it"
[06:21:58] <Boomtime> not even two stage commit can make this possible, this result is the classic "two generals problem" in action
[06:27:45] <sgo11> Boomtime, sorry, maybe because of my weak English, I am confused with the words "discounting in-memory changes". I think you mean even if in-memory does not change, clients can still read the modified result. Is what I understand correct?
[06:30:57] <sgo11> I can understand all the words except "the first point is possible in many conditions, even discounting in-memory changes". If in-memory data does not change, how can I client read the change? (sorry if my words don't make sense).
[06:41:31] <Boomtime> sgo11: memory must change, you can't read or write anything until the memory changes
[06:44:17] <sgo11> Boomtime, ok. thanks. whatever readers see the change before the writer receives write response from mongod. ^_^
[06:47:47] <Boomtime> sgo11: readers *might* see the change before the writer receives the response
[06:48:32] <Boomtime> this is true of all databases
[06:51:37] <sgo11> Boomtime, got it. thank you very much. ^_^
[10:44:19] <GothAlice> Happy festivus, x-mas, Hanukah, or other winter solstice festival as appropriate y'all!
[12:30:12] <laurensvanpoucke> I'm using MEAN stack. What's the 'best' option for storing images for a user? On aws s3 and link in mongodb?
[12:36:04] <GothAlice> laurensvanpoucke: Best is subjective. I use both the S3 approach (easy HTTP access for clients without any additional work) and GridFS (historical data archival) approaches.
[12:45:32] <GothAlice> Unfortunately because of the scale of some of my data, GridFS is the only option. (S3 is hideously expensive, as are most "cloud storage" services. For my level of data it'd cost $26,000 for the first year or so. See: http://cl.ly/image/0t1x2Q2L1u0E)
[12:48:03] <GothAlice> I realized early on, however, that for those prices I could afford to replace every drive in a Drobo… every month.
[12:49:25] <GothAlice> laurensvanpoucke: I asked the Dropbox guys at a conference once if they could help me. They turned white and started muttering "noonoonoooo". ^_^
[12:52:00] <GothAlice> The Drobo arrays (typically the most expensive RAID you can get… but lowest maintenance) were paid off in four months via savings of not using a cloud hosting provider.
[12:55:53] <GothAlice> laurensv_: http://cl.ly/image/1e243W0V1b0B < backlog of what you may have missed
[13:06:44] <GothAlice> laurensv_: Pardon the linkyness, but when I shopped around and came up with that chart I went through the stages of grief. At first I was like http://cl.ly/image/3k3w0O0N1K1I then I was like http://cl.ly/image/2J242J2w3H1t then I got sad like http://cl.ly/image/2H082X2m2q38 and finally ended up http://cl.ly/image/090o3y2s0q1a (reaction gifs)
[14:34:05] <chetandhembre_> if i set read preference for secondary in cluster.. i have replica set as shard in cluster .. does read goes to secondary of replica set ?
[15:25:37] <mitzip> GothAlice: for your 24tb where do you get your bandwidth to the outside world from with drobo?
[15:26:18] <GothAlice> A rather terrible cable connection, actually. It's my personal "at home" dataset. Took four months or so for the initial off-site backup. ;)
[15:27:32] <GothAlice> My ISP was silly enough to forget a bandwidth cap on my contract, and my apartment complex was silly enough to include a flat fee for electricity in my rental agreement. >:3
[15:28:11] <GothAlice> I've only barely resisted the urge to turn my apartment into a Bitcoin miner. The whole apartment. XP
[18:09:35] <chetandhembre_> can i set read preferences in mongos ?
[21:21:37] <buubo> i have arrays 0 => 'name' = 'lala' / 1 => 'name' = 'uuu' how to findOne ? when i don't know which number it is but i know the name which is inside the array
[21:30:16] <buubo> how to find a document when i have arrays like 0 => array / 1 => array / 2 => array and i don't know the number i just know the inside like name ..
[22:17:06] <buubo> guys i want to locate some field = value in my deep document and than add to that existing array more fields = values what do i need ? only mongodb update?