Log file Viewer
#mongodb logs for Thursday the 10th of October, 2019
[18:29:45] <syntaxfree> is there a document-oriented, mongo-like (in the sense of the api offered) in-memory "light" database in the style of sqlite?
[18:32:09] <GothAlice> The schema you define for your “table” is essentially meaningless. Declare an integer field, stuff a string into it, no worries.
[18:33:22] <GothAlice> One could, relatively trivially, implement a document-like store on top of SQLite using EAV. https://en.wikipedia.org/wiki/Entity-attribute-value_model
[18:33:41] <syntaxfree> 'm writing a facesmash-type thing in which people are presented with two choices and Elo-type ratings are kept.
[18:34:18] <GothAlice> Then you have absolutely no _need_ for document storage. Almost anything could satisfy the requirements.
[18:34:21] <syntaxfree> I was using sqlite because the state I needed to persist was just object:current-score. I would serialize dicts to json, but wanted to learn something.
[18:35:05] <GothAlice> Of note: SQLite is write-locked, preventing parallel updates. Write-heavy (*especially* multi-user) loads should avoid SQLite like the plague.
[18:35:52] <syntaxfree> and now I have a table of matches. I can gert the last match for any object, ok.
[18:36:33] <syntaxfree> but it keeps getting complicated. now objects have attributes. so I can later approximate the choice structure with an SVM or somesuch.
[18:36:44] <GothAlice> “History” in that setup is just another table, use of the term “object” is misleading—it’s a “record”. UPDATE scores …; INSERT INTO history …
[18:37:21] <GothAlice> In MongoDB, you don’t store the complete history for a document within that document, that way lies madness and the document size limit.
[18:37:31] <syntaxfree> well, before, uh, individuals have attributes, you jsut need the history table.
[18:39:28] <GothAlice> If you store your *current* data *and* historical data in the same table/collection, then every query must, essentially, wade past the historical data that 99% of the time, never want.
[18:39:33] <GothAlice> “Individuals have attributes” → really, really look into EAV. Entity, Attribute, Value. It’s the phrase you used, using the correct database-domain terminology. ;P
[19:54:08] <Texan> i would like to update documents across ALL shards. im currently running this query and running into an error
[19:54:13] <Texan> query: db.products.updateMany({ "_id" : { $exists: true }}, { $set : { 'tags': []}})
[19:55:20] <Texan> but ultimately i want to update this across all the shards (i just want to clear out the tags field)
[19:58:38] <GothAlice> Texan: Why on Earth are you checking for the existence of _id? How does one even create a document missing that key?
[19:59:13] <GothAlice> (The server adds it if missing. The application driver adds it if missing before handing it off to the server. Many DAOs, including mine, eagerly populate it before ever sending off to the driver or server. Etc.)
[19:59:38] <Texan> so ill preface this with i dont know what im doing :) but essentially i thought that if i put in the _id $exists it would stop moaning about me not providing a shard key lol
[20:26:03] <Texan> hate to pester, but really at a loss for how to do this. anyone have any suggestions?