00:08:20  * neonstalwartquit (Quit: Leaving.)
00:21:42  * ednapiranhajoined
00:27:32  * stagasjoined
01:04:08  * stagasquit (Ping timeout: 250 seconds)
01:15:29  * ryanjquit (Ping timeout: 258 seconds)
01:47:18  * yarongjoined
01:47:58  <yarong>Is there any hope of https://github.com/rvagg/node-levelup/wiki/Plugin-Pattern-Discussion#conditional-update--merge being resolved in the near future?
01:50:10  <rvagg>yarong: not unless you want to put in the work
01:51:02  <yarong>rvagg: Fair enough. I am curious though, how do levelup users implement conditional updates without losing their minds?
01:51:32  <rvagg>we've mostly lost our minds so no big deal on that front
01:51:49  <rvagg>yarong: this may be helpful: https://github.com/mikeal/level-mutex
01:51:51  <yarong>rvagg: I don't suppose I can argue with that. :)
01:53:11  <yarong>rvagg: I missed that one, I found level-atomic, levelplus, level-updater, level-update and now you pointed to level-mutex. It seems like lots of people take a wack at this problem and then wander away. That usually means it's much harder than it looks.
01:54:28  <yarong>rvagg: BTW, the reason I care is because I'm running into data corruption issues with PouchDB on node.js using LevelDB. I'm trying to read Pouch's leveldb.js file (where they wrap level up) and honestly, I'm not smart enough to grok it. But I think a lot of the complexity is because it has its own hacked in solution for the problem and as the data corruption strongly implies, it doesn't work.
01:55:11  <yarong>rvagg: But to be fair I have no proved that the data corruption was a result of faulty condition update logic, but it does seem likely.
02:06:22  * ednapiranhaquit (Remote host closed the connection)
02:20:51  * dguttmanjoined
02:54:52  * blessYahu_joined
03:39:57  * ednapiranhajoined
03:42:32  <rvagg>yarong: yeah, the conditional update is a primitive that I wish we had
03:43:28  <rvagg>unfortunately leveldb doesn't provide one and we'd have to hack in a write mutex to make it work
03:44:34  * ednapiranhaquit (Ping timeout: 265 seconds)
05:13:24  * ryanjjoined
05:23:42  * ryanjquit (Ping timeout: 250 seconds)
05:41:56  * blessYahu_quit (Ping timeout: 264 seconds)
06:43:08  * dguttmanquit (Ping timeout: 264 seconds)
08:19:08  * bonswouarjoined
11:00:41  * bonswouarquit (Remote host closed the connection)
11:45:39  * stagasjoined
12:04:55  * joakinojoined
12:08:09  * tarrudajoined
12:11:29  * tarrudaquit (Client Quit)
12:12:29  * tarrudajoined
12:46:15  * joakinoquit (Read error: Connection reset by peer)
12:46:21  * joakino_joined
13:27:31  * joakino_quit (Read error: Connection reset by peer)
13:27:37  * joakinojoined
13:39:54  * tarrudaquit (Quit: WeeChat 1.0.1)
13:40:52  * tarrudajoined
14:09:14  * joakinoquit (Read error: Connection reset by peer)
14:09:19  * joakino_joined
14:50:34  * joakino_quit (Read error: Connection reset by peer)
14:50:40  * joakinojoined
15:11:35  * jjmalinajoined
15:54:12  * tarrudaquit (Ping timeout: 250 seconds)
16:07:31  * joakinoquit (Read error: Connection reset by peer)
16:07:32  * ramitosquit (Remote host closed the connection)
16:07:37  * joakino_joined
16:08:04  * ramitosjoined
16:16:20  * jjmalinaquit (Quit: Textual IRC Client: www.textualapp.com)
16:24:45  <ogd>yarong: i use level-mutex and it does the job well, you just have to write code in a race-condition sensitive way when using it
16:41:03  * joakino_quit (Read error: Connection reset by peer)
16:41:08  * joakinojoined
17:22:32  * joakinoquit (Read error: Connection reset by peer)
17:22:38  * joakino_joined
17:37:32  * ramitosquit (Read error: Connection reset by peer)
18:03:51  * joakino_quit (Read error: Connection reset by peer)
18:03:57  * joakinojoined
18:15:03  * blessYahu_joined
18:26:22  * ednapiranhajoined
18:45:21  * joakinoquit (Read error: Connection reset by peer)
18:45:27  * joakino_joined
18:50:57  * tarrudajoined
19:03:40  * joakino_quit (Remote host closed the connection)
19:10:52  * tarrudaquit (Ping timeout: 240 seconds)
20:19:15  * phpnode_quit (Ping timeout: 252 seconds)
20:29:46  * ednapiranhaquit (Quit: Leaving...)
20:33:02  * phpnode_joined
20:38:59  * mitzipquit (Ping timeout: 255 seconds)
20:44:48  * mitzipjoined
21:28:14  * tarrudajoined
22:31:35  * phpnode_changed nick to phpnode
22:40:55  * yarongquit (Ping timeout: 255 seconds)
22:49:08  * yarongjoined
22:54:45  * yarong2joined
22:56:23  * yarongquit (Ping timeout: 272 seconds)
23:07:45  * yarong2changed nick to yarong
23:10:33  <yarong>ogd - level-mutex was certainly designed for the exact same scenario I'm worried about. But I'm still trying to convince myself it will work if multiple independent requests come in that all have conflicting writes. Honestly it would seem easier to just hook the put/get/batch API calls directly and just track the version ID for any GETs that way. But I'm probably missing something.
23:23:37  * rudquit (Quit: rud)
23:27:17  * tarrudaquit (Ping timeout: 240 seconds)