mgo, the package for golang to operate MongoDB is like a pot of shit!

In general, I need to define a struct to tell mgo, which fields I need, for example:

type PrivacyInfo struct { Phone string bson:"phone" Id bson.ObjectId json:"id" bson:"_id,omitempty" } But, I have so many collections, which the name of phone number is different, such as "TelephoneNumber", "Number", "MobileNumber" and etc. I don't know which collection I will use until the program is running. So I hope I can input the collection name and the field name and then the program read the number.

But in golang, compare with Python's pymongo or even MongoDB's default shell, mgo is really a pot of shit!!!

---

评论：

TheMue:

Maybe it's simply due to the data structure. Lists of tuples with type and number would be more flexible and better searchable. Blaming a database driver doesn't help. 

ligustah:

I don't think this has anything to do with mgo. If you don't know the schema upfront you'll just have to use bson.M{} and then figure out the parts you need (there are libraries to help with that). That's the price you're paying to be schema-less.

kingname:

Schema can not work. Because it need declare a struct first and then can it transfer a map to struct. But before I input the name of a field, how can I declare a struct?

ligustah:

I think some of the other answers already provided good explanations on this.

TheMue:

The driver is intended to serialize data structures and use Mongo for persistency (top-down). You instead want to access a number of different structured documents (bottom-up).

It's like trying to hammer a nail with a screwdriver and then blame it that it doesn't work. But it's very good for screws where a hammer fails. 

kingname:

Is there a "hammer" to solve my problem in Golang?

TheMue:

Most generic datatypes regarding marshaling of JSON are interface{}, []interface{}, or map[string]interface{}. These structures are nested then. These interfaces are statically typed then when doing the unmarshaling, but you have to work with type assertions if the may vary.

While JSON has this flexibility a static-typed language like Go is a bit more complex here. That's why it's so positive to know your data structures well. We do the same here with CouchDB. We simply serialize our types into the DB and later retrieve them, as deep nested structures.

aboukirev:

Correction, the data structure you working with is at fault.
All you have to do is use a map or Dtype frombson sub-package as a target result when working with Query and BSON will be unmarshaled/deserialized just fine into it.  Then you can examine it to your heart's content.

The relevant documentation is at http://godoc.org/gopkg.in/mgo.v2/bson#Unmarshal

kingname:

Thanks for the document, I will read it carefully.

smartsam69:

In my experience, a programmer that tries to blindly blame the tools is usually the one at fault

tsdtsdtsd:

Maybe check out the official mongo-tools sources at https://github.com/mongodb/mongo-tools

Most (or all?) are written in Go and use mgo, without the structs.

Still, for me the structs are great. Clean code enforcing, strictly typed awesomeness. I don't get how someone could hate that so much.

kingname:

OK, I will read it. Thanks a lot.

Patchthesock:

What pot of shit did you use to compare? Why not use a better maybe more agnostic data structure? As TheMue has said blaming a database driver isn't going to help.

kingname:

MongoDB‘s shell is 10000 times better than mgo, and let alone pymongo

carsncode:

You're comparing apples and Bolivia. The shell isn't a DB SDK, that's a pointless comparison. Python and Go are very different languages, so pymongo is a slightly better but still inapplicable comparison.

kingname:

A man who write a database driver to wrap the origin api is aim to make it more usable. But mgo back the car, it makes MongoDB so hard to use.

kingname:

Any one who is familiar with pymongo or mongoengine or even MongoDB's default shell will say, mgo is a pot of shit!. 

skidooer:

...so don't use it?