[08:51:47] <pawkor> Hi, I have login issues with 4.2.1 cluster, fresh install, 2 mongos servers, 3 config servers, 3 shards with 3 replicas, security: keyFile, replication works, replicas connect to config servers but when I try to login to mongos or any of the replicas I'm getting 'Error: command getParameter requires authentication'. User added via mongos server to database admin with roles root, userAdminAnyDatabase, clusterAdmin, readAnyDatabase, readWriteAnyDatabase, dbAdminAn
[09:00:02] <pawkor> I'm stupid, didn't add keyFile to mongos, sleeping 3 hours is bad idea,
[12:14:27] <funabashi> Hi how can change owner of all files in /var/lib/mongdb ?
[19:11:29] <lcneves> Hi. I need to search for thousands of small documents at once. Is it better to build one giant query with thousands of '$or' elements, or thousands of parallel simple queries?
[19:13:43] <GothAlice> Neither; pivot your data to make it actually queryable. ;P Both naive approaches will “get it done”, but each suffers from problems. The first, thousands of $or, essentially means the query planner will have no choice but to give up attempting to optimize the query (resulting in collection scan), I believe.
[19:15:34] <GothAlice> The latter implies thousands of round-trips, and you will absolutely fail to “parallelize” that. MongoDB operates in a “linear reality” where no two operations can ever really happen simultaneously. Read, update, read, that second read will get the result of that update. (Single-node. Replica set and you start losing behaviours unless you explicitly ask for them, e.g. “linearizable”.)
[19:16:38] <GothAlice> Instead, try to formulate some new attribute you can add to the records to identify their relevant grouping. Query against that instead.
[19:18:14] <lcneves> GothAlice: Thank you, that was very informative.
[19:22:22] <GothAlice> lcneves: Case example: logging records. I log to MongoDB all Python logged messages, and with them I include “extra” data (log.info(“Hi”, extra=dict(…)) which gets serialized into the DB record. All related entities associated with that log entry have their ObjectId (actually DBRef) stored in the “actors” array of that log entry. Makes lookup (in various groupings) trivial.
[19:22:29] <GothAlice> E.g. per-user, per-organization, per-feed, etc., etc.
[20:34:01] <GothAlice> So, in your case, don’t use getCollectionNames (or equivalent) get their full info. Enumerate that, skipping ones whose type is “view”.
[20:34:26] <GothAlice> (The parameter to getCollectionInfos is a filter document I’m using to seek out that one view for testing.)
[20:35:46] <GothAlice> So, actually… db.getCollectionInfos({“type”: {“$ne”: “view”}}) — get everything except views. :)
[20:46:43] <markizano> I like the concepts. They are really kewl!
[20:50:19] <GothAlice> Introspection and reflection. I believe these “get more info” type functions make this “reflection”. I *think*.
[21:00:06] <markizano> all I know is I am most likely not the only person who's searched for this, so hopefully the Google's will find this and make it easier for someone else ^_^