So, my experience is all with relational DBs (mssql) mainly and this job is the first time I've had to deal with mongodb.

I'm using the default compass client and I'm struggling with just how shit it is.
- A default font size of 5px high which resets every time it starts.
- Total lack of keyboard shortcuts.
- Inconsistent expansion& folding behaviours
- No saving of aggregates/queries if you accidentally click on another collection.
- ittle bitty query window which is actually multi line but with no scrollbar...
The list goes on.

And mongodb, whoever thought JavaScript is an appropriate query language... It's not.
It's probably because I don't have enough experience with it but the mix of quotes and $ seems so random...

So, you are using a NoSQL DB for the first time and your first impressions are on the IDE and one of the client side language it supports

@asgs
Tools matter a lot.
Imagine the extreme of having to write code by punching holes into cards...

@Oktokolo yeah but what if you don't know what to punch or how

Okay so I actually have quite a bit of experience with this and I feel for you so let me help you out maybe:

- Mongo DB itself is nice. It has its flaws and there are really good technical reasons you might not want to use it, but for general usage it's built well.

- Pretty much all of the client libraries for it suck, across the board. This is because the intense CS aspect of the database is implemented by an entirely different team than the OSS tooling aspect of it.

- Robot 3T is the one and only tool I'd ever reccommend for interacting with Mongo.

- It's not javascript, it's BSON (which, yes, sucks). The $ prefix is to differentiate mongo-related functions from data keys. If you have javascript, that's a tool allowing you to do that - not Mongo itself. You shouldn't be writing javascript as queries because you're probably locking yourself in to some weird third-party magic add-on. Your queries should look like JSON, more or less.

@asgs
I certainly would still know for sure, that writing text in any language sucks hard when you have to use a card puncher for it.
Even though i never actually used a card puncher before.
And even though i know for sure, that card punchers where used for writing good code in the past.
Also even though i never wrote any code in any computer language that was modern back when they actually used punch cards.

Yes, if you have some experience using any tool of a similar category for any task of a similar category, you actually will not be far off the truth most of the time when roughly judging tools by first impression.

And even if not, you are still right assuming a hammer made of pudding to have only very limited set of use cases - of wich not a single one involves the driving of nails into anything...

@Oktokolo Literally have no idea what this comment means. It only serves to confuse.

> Also even though i never wrote any code in any computer language that was modern back when they actually used punch cards.

There were no "languages". That was the point of punch cards.

Also wtf does any of this have to do with mongodb?

@Oktokolo so, we are talking about tools (like IDE) to use bigger and wider tools (like MongoDB) in this case

If punching holes or writing code in one of the then modern languages doesn't get the job done, it is only natural to choose the best option, it is only natural to evolve the tools to those tools, create new tools to interact with those tools or avoid the said tools altogether and start looking froma different perspective

I used compass for only a short period and I still prefer mongo cli or the Robo3T community edition over any other tool as gets the job of transferring the commands to the remote db server and providing feedback on it. If anything, I had problems with the database itself and tools like the one mentioned above barely interfered

Ok, more comments here than I was expecting :)

Yeah, I'm criticising the client mainly because that's how I interface with the DB. And I _know_ that I don't know enough about the DB to criticise it. Stuff that seems wrong from a RDB isn't wrong, just different. And my fundamental approach to ordering/accessing data must change.

But I get to bitch about shitty UX in a client because I know it's shit.

And yes, it's BSON not JavaScript. It just seems so... clunky with all the (to me anyway) extra brackets and new rules I don't know yet. (yeah, I know, learn the fucking language before bitching... but this is my first impression)

The DB itself is fine. Mongo has a bad reputation but I haven't had any problems with it. And it's allowed us to scale up very nicely.

I do wish there was a way to actually forbid queries which don't use an Index (like RavenDB). I guess I have to stop being lazy and look at our metrics... :(

@junon Oh and thanks for the tip on Robo3T I'm giving the community edition a try.

Is there any big advantage with the paid version?

@DasKoder I couldn't tell you, been a while since I used it.

The queries themselves are not javascript per se, they just look like that and translate down to lower level commands on the wire. You get used to it.

As for index checks, append `.explain("executionStats")` to any of your queries and look for the execution plan property. That tells you if there was a full scan or if there was an index hit, and a few other interesting pieces of info. No metrics system needed - you can make sure queries are performant before you add them to your application.

Also, remember that index creation queries are idempotent (at least, they were when I last used mongo), so creating indices upon boot of your service is a safe operation and allows you to migrate them nicely. 100 instances of your service all creating the same index will only have an effect the very first time it is run. Keeps things simple.

@junon
So Fortran is not a computer language for you?
https://en.wikipedia.org/wiki/...