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

<p>In general, I need to define a struct to tell mgo, which fields I need, for example:</p> <p><code> type PrivacyInfo struct { Phone string `bson:&#34;phone&#34;` Id bson.ObjectId `json:&#34;id&#34; bson:&#34;_id,omitempty&#34;` } </code> But, I have so many collections, which the name of phone number is different, such as &#34;TelephoneNumber&#34;, &#34;Number&#34;, &#34;MobileNumber&#34; and etc. I don&#39;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. </p> <p>But in golang, compare with Python&#39;s pymongo or even MongoDB&#39;s default shell, mgo is really a pot of shit!!! </p> <hr/>**评论：**<br/><br/>TheMue: <pre><p>Maybe it&#39;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&#39;t help. </p></pre>ligustah: <pre><p>I don&#39;t think this has anything to do with mgo. If you don&#39;t know the schema upfront you&#39;ll just have to use <code>bson.M{}</code> and then figure out the parts you need (there are libraries to help with that). That&#39;s the price you&#39;re paying to be schema-less.</p></pre>kingname: <pre><p>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?</p></pre>ligustah: <pre><p>I think some of the other answers already provided good explanations on this.</p></pre>TheMue: <pre><p>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).</p> <p>It&#39;s like trying to hammer a nail with a screwdriver and then blame it that it doesn&#39;t work. But it&#39;s very good for screws where a hammer fails. </p></pre>kingname: <pre><p>Is there a &#34;hammer&#34; to solve my problem in Golang?</p></pre>TheMue: <pre><p>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.</p> <p>While JSON has this flexibility a static-typed language like Go is a bit more complex here. That&#39;s why it&#39;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.</p></pre>aboukirev: <pre><p>Correction, the data structure you working with is at fault. All you have to do is use a map or <code>D</code>type from<code>bson</code> sub-package as a target result when working with <code>Query</code> and BSON will be unmarshaled/deserialized just fine into it. Then you can examine it to your heart&#39;s content.</p> <p>The relevant documentation is at <a href="http://godoc.org/gopkg.in/mgo.v2/bson#Unmarshal" rel="nofollow">http://godoc.org/gopkg.in/mgo.v2/bson#Unmarshal</a></p></pre>kingname: <pre><p>Thanks for the document, I will read it carefully.</p></pre>smartsam69: <pre><p>In my experience, a programmer that tries to blindly blame the tools is usually the one at fault</p></pre>tsdtsdtsd: <pre><p>Maybe check out the official mongo-tools sources at <a href="https://github.com/mongodb/mongo-tools" rel="nofollow">https://github.com/mongodb/mongo-tools</a></p> <p>Most (or all?) are written in Go and use mgo, without the structs.</p> <p>Still, for me the structs are great. Clean code enforcing, strictly typed awesomeness. I don&#39;t get how someone could hate that so much.</p></pre>kingname: <pre><p>OK, I will read it. Thanks a lot.</p></pre>Patchthesock: <pre><p>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&#39;t going to help.</p></pre>kingname: <pre><p>MongoDB‘s shell is 10000 times better than mgo, and let alone pymongo</p></pre>carsncode: <pre><p>You&#39;re comparing apples and Bolivia. The shell isn&#39;t a DB SDK, that&#39;s a pointless comparison. Python and Go are very different languages, so pymongo is a slightly better but still inapplicable comparison.</p></pre>kingname: <pre><p>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.</p></pre>kingname: <pre><p>Any one who is familiar with pymongo or mongoengine or even MongoDB&#39;s default shell will say, mgo is a pot of shit!. </p></pre>skidooer: <pre><p>...so don&#39;t use it?</p></pre>