Log file Viewer
#mongodb logs for Friday the 8th of July, 2016
[07:20:45] <jbu> Hi all, Each of my docs has an array in field "path". I want to find all docs that have an element in the array "path" that matches one of my few input values. The following query doesn't work. Can you have an "in" in the "$eq"? { "tid" : 4444 , "del" : { "$ne" : true} , "path" : { "$elemMatch" : { "$eq" : { "$in" : [ "577f515fd27c1e17145dc8b6"]}}}}
[07:21:31] <jbu> let me shave down the query for you, so you can rule out the tid/del clauses: {"path" : { "$elemMatch" : { "$eq" : { "$in" : [ "577f515fd27c1e17145dc8b6"]}}}}
[07:22:02] <jbu> this returns nothing, despite there being a few documents with the path array containing the element "577f515fd27c1e17145dc8b6"
[07:30:05] <Kralian> I've only tried in mongodb, where I'd write { "path" : { "$in" : { [ "577f515fd27c1e17145dc8b6"] }}}
[07:31:28] <kurushiyama> db.yourcoll.find({path:'577f515fd27c1e17145dc8b6'}) should work perfectly to fetch the doc.
[07:31:38] <jbu> kurushiyama, I will have multiple values to check this is more accurate: {"path" : { "$elemMatch" : { "$eq" : { "$in" : [ "577f515fd27c1e17145dc8b6", "someotherid", "yetanotherid"]}}}}
[07:35:35] <kurushiyama> jbu To answer your question: Yes, even when path is an array. It gets expanded automaticaly. It would be something different if path was an array of subdocs.
[07:36:00] <jbu> kurushiyama, thanks, I'm trying to understand now, give me a moment...very new at this
[07:37:15] <jbu> your pastebin doesn't make sense to me, you're not passing in a list of elements in which any element of path can be
[07:37:56] <jbu> kurushiyama, I will have multiple values to check this is more accurate: {"path" : { "$elemMatch" : { "$eq" : { "$in" : [ "577f515fd27c1e17145dc8b6", "someotherid", "yetanotherid"]}}}}
[07:40:01] <kurushiyama> jbu You will find the community is pretty unforgiving regarding that. Especially since the docs are very well written, when compared to other DBMS.
[07:41:01] <kurushiyama> One thing to denote on "$in": avoid to use it with arbitrary length arguments. When given more than a few dozens, it gets a performance killer.
[07:42:33] <kurushiyama> jbu While changes theoretically are easy, they are only to a certain extend.
[07:43:03] <jbu> I absolutely believe you, we're already running into many problems because we chose a doc db for certain parts of our app that are more relational, requiring heavy joining
[07:45:19] <kurushiyama> jbu Stop me when I am wrong, but basically you seem to store the relation in the 1 part of a 1:n relation.
[07:47:36] <kurushiyama> jbu In 9 out of 10 cases, that is the wrong way, especially when n> tinyint.
[16:08:40] <Pinkamena_D> I get the error "cant take a write lock while out of disk space" in the mongo shell, even while trying to delete data. I have credentials to the mongo database but not the root user of the machine. Is there anyway to clear space?
[16:16:26] <Pinkamena_D> Based on what I am reading elsewhere, it seems like I will have to find a root user somewhere to have a chance to get it working again. To avoid this problem in the future, can I configure mongo to not write past a point where I an not able to delete anymore?
[16:18:08] <Pinkamena_D> Backups? Yes, but the data is still there fine, I can read it, I just logged too much during an experimental script and I need to remove what I have written, but I can not.
[16:18:40] <cheeser> bad idea #1: you can try dropping an index to reclaim some space. clean up data. recreate index.
[16:21:11] <Pinkamena_D> I cant imagine that a remove operation needs that much disk space, why is it not possible to preserve the required amount?
[16:25:08] <Pinkamena_D> I don't fully understand it, but it seems as though to DELETE a record, extra disk space is required. (else, why cant I proceed?) so whatever this amount is.
[16:25:39] <Pinkamena_D> Indeed, 5% space is available, but that is out of scope for this problem I think
[16:26:01] <kurushiyama> Pinkamena_D Well, the problem really is that the system was not monitored properly. Imho.
[16:26:46] <Pinkamena_D> Yes, but for later, I want to only continue to write until 1MB is left, and then only removes will work.
[16:27:34] <kurushiyama> Running a production system without monitoring is like flying a fighter jet through the alps blindfolded.
[16:28:49] <Pinkamena_D> The data I was working with, does not allow room for that approach from my perspective. If I write very quickly a large amount, no time for human intervention will be possible, I need something automated.
[16:31:22] <kurushiyama> Pinkamena_D In more sophisticated setups, I have additional warnings when the data growth exceeds standard deviation.
[16:33:03] <kurushiyama> Pinkamena_D Usually, my shards are on the sweet spot, anyway – the point where I get the moset bang for the buck. If I know I will need a shard sooner or later, I set up single shard clusters.
[16:36:47] <kurushiyama> I already have an Amazon subscription (SO does her masters, so we get it almost for free).
[16:40:08] <kurushiyama> Will have a look into it. We are a bit behind in Europe regarding TV. Actually I enjoyed watching 8 simple rules to date my daughter, recently. I was shocked Ritter is dead.