00:16:12  * rgrinbergquit (Ping timeout: 256 seconds)
02:03:44  * jerrysvjoined
02:21:15  * jerrysvquit (Remote host closed the connection)
02:48:19  * syntaksjoined
02:48:24  <syntaks>hiya folks
02:48:42  <syntaks>would there be any foreseen issues in storing plain json as a value in leveldb?
02:53:25  <substack>you can use valueEncoding: 'json' and leveldb will encode and decode json values automatically
02:53:50  <syntaks>substack: appreciate the response
02:54:00  <syntaks>essentially what i'm looking to use it for is more or less a forum
02:54:14  <syntaks>in a portable, peer-to-peer app
02:54:38  <syntaks>the only hurdle so far i can't seem to chew on, is whether or not i should open up several dbs or not
02:54:57  <substack>a model that works well for that is a kappa architecture where clients write to an append-only log
02:55:23  <substack>and then you write materialized views which creates indexes that answer queries faster than reading the whole log
02:55:40  <substack>I recommend https://npmjs.com/package/hyperlog if you want to implement this
02:55:40  <syntaks>interesting i've never heard of that before
02:55:47  <syntaks>ah i would, however, c++
02:56:13  <syntaks>am i wrong in thinking to split up databases based on content?
02:56:18  <substack>oh right, yea this channel is mostly about the nodejs and IndexedDB browser bindings
02:56:20  <syntaks>e.g.: 'posts.db', 'comments.db'
02:56:28  <syntaks>comments having the post ID as the key
02:56:37  <substack>it doesn't matter very much
02:56:46  <syntaks>i was thinking in terms of executions
02:56:53  <syntaks>fetching each associated
02:57:07  <substack>the main question is if you'll need to perform atomic writes to comments and posts simultaneously
02:57:21  <syntaks>nod, that was a concern
02:58:17  <substack>but if you're building a p2p forum, a log is the way to go
02:58:36  <substack>then you build indexes from the log which can be modified or regenerated
02:58:58  <syntaks>well it will be limited by 1 minute waits
02:59:05  <syntaks>and as they all come in processed and written
02:59:21  <syntaks>so it wouldn't be comment->saveToDB(), comment->saveToDB()
02:59:27  <syntaks>it would be in a loop essentially
02:59:38  <syntaks>for comment in <incoming>; process->save
02:59:39  <substack>the logs are more to do with how you would implement data replication
02:59:52  <syntaks>replication's already handled via a transaction system
03:00:13  <syntaks>it comes in through that, the system processes it for the type of data, then acts on it and saves it to local db
03:00:58  <substack>how does peer to peer fit into your scheme?
03:01:17  <syntaks>it's already built atop a network
03:01:30  <syntaks>as the data comes through the functions that process it can parse the headers
03:01:31  <substack>when I think peer to peer I think of clients that replicate with each other instead of centralized servers
03:01:46  <syntaks>the data's broadcasted through the network from peer-1
03:01:56  <syntaks>the rest receive it and the function the processes it saves it
03:17:47  * jerrysvjoined
03:51:42  * jerrysvquit
03:53:11  * jerrysvjoined
03:55:12  * jerrysvquit (Client Quit)
04:02:12  * jerrysvjoined
04:18:21  <syntaks>hmm
04:18:24  <syntaks>this is interesting
04:18:29  <syntaks>https://github.com/Softmotions/ejdb
05:02:00  * jerrysvquit (Remote host closed the connection)
12:17:47  * rgrinbergjoined
12:19:20  * Axyjoined
12:22:24  * Miaquit (Ping timeout: 244 seconds)
13:48:34  * Miajoined
13:50:56  * Axyquit (Ping timeout: 260 seconds)
16:08:51  * rgrinbergquit (Ping timeout: 265 seconds)
17:46:25  * rgrinbergjoined
21:32:00  * rgrinbergquit (Ping timeout: 260 seconds)