still active?

[qhenkart]

Is this library still active? I see it's been over a year since a release was made. We need to use ArrayFilters and I notice they are on the development branch from a year ago but not on an official release. Is this library still being maintained?

[SchumacherFM]

I don't think so ... we're switching to https://github.com/mongodb/mongo-go-driver

[SchumacherFM]

Once understood, the official driver speeds up the code, lowers allocations and even simplifies code.

[ansoda]

I use a lot of mgo in my projects，I want to Implement mgo interface via mongo-go-driver。

[eaglerayp]

@domodwyer could anyone answer the project status?

[qhenkart]

After not receiving a clear response. I think we can all conclude that the community drivers are no longer being maintained. As a result I began migrating to the official driver. I found the most brittle and frustrating aspect of the official driver to be the primitive.ObjectID package and handling objectIDs as [12]bytes instead of strings like the community package did. So I combined the best of both and made this package. I hope it helps people here

With the package, the migration really isn't so bad https://github.com/qhenkart/objectid-go

[domodwyer]

Hi all,

Unfortunately I no longer work at GlobalSign - as a result, I don't have access to the test infrastructure that made maintaining mgo possible, and I guess my old team have different priorities now.

As MongoDB have a stable, official library I encourage all new projects to use it, and where possible, migrate existing projects - they have both the time, and resources to develop and refine it in lock-step with new mongo feature releases. Now seems like a good time to deprecate mgo.

Sorry, it was fun while it lasted! Dom

[mwmahlberg]

@domodwyer It would be nice by globalsign to at least state this on the README, and/or archive the repository. Maybe you can give your old colleagues a shout about that?

[RDux]

Would be nice if this driver continued to live. The official driver is horrible. I noticed that my app started consuming a lot of memory when working with gridFS. After digging through the official driver code a bit it quickly becomes clear that it's quite poorly written.

After running a benchmark with 50 concurrent requests for a 50ishMB video the system monitor reports my app using 1.9GiB of memory with the official driver. With the same benchmark against this driver memory sits at 53MiB.

It's quite easy to spot where the problem lives when looking at the live allocation profile of the official driver.

Showing top 20 nodes out of 38
      flat  flat%   sum%        cum   cum%
109148.24MB 98.74% 98.74% 109148.74MB 98.74%  go.mongodb.org/mongo-driver/x/mongo/driver/topology.(*connection).readWireMessage
  818.36MB  0.74% 99.48%   818.36MB  0.74%  go.mongodb.org/mongo-driver/mongo/gridfs.newDownloadStream

(pprof) list readWireMessage
Total: 107.95GB
ROUTINE ======================== go.mongodb.org/mongo-driver/x/mongo/driver/topology.(*connection).readWireMessage in /home/RDux/Code/Go/src/go.mongodb.org/mongo-driver/x/mongo/driver/topology/connection.go
  106.59GB   106.59GB (flat, cum) 98.74% of Total
         .          .    249:   // read the length as an int32
         .          .    250:   size := (int32(sizeBuf[0])) | (int32(sizeBuf[1]) << 8) | (int32(sizeBuf[2]) << 16) | (int32(sizeBuf[3]) << 24)
         .          .    251:
         .          .    252:   if int(size) > cap(dst) {
         .          .    253:       // Since we can't grow this slice without allocating, just allocate an entirely new slice.
  106.59GB   106.59GB    254:       dst = make([]byte, 0, size)
         .          .    255:   }

I've attempted to fix it in the official driver but the code base is just a mess so I think I'll drop using MongoDB all together. I sure as hell don't want to rely on the official driver in its current condition.

[qhenkart]

@RDux you should make a post on their issues page https://jira.mongodb.org/projects/GODRIVER/issues/

I have not had any luck with the bugs I have posted there, they usually say the bugs are intentional, which is pretty frustrating. But it's worth a try

[mwmahlberg]

@RDux I agree with @qhenkart here. 1.9GB seems way out of proportion, though I have not encountered this behaviour. Can you share the relevant code as a gist (and/or a question on SO, maybe)?

[RDux]

@mwmahlberg Here is a gist with a simple example that triggers the behavior. https://gist.github.com/RDux/1c9eb8c2a3a75b94f2f9f8d19ff90f9a

[FM1337]

This is disappointing, the official mongodb driver for golang (mongo-go-driver) is in my opinion confusing and too much of a hassle to migrate over to from mgo in its current state. I still thank you for maintaining it as long as you did.

[mwmahlberg]

@RDux Sorry, I have not come to testing this. Will try this week.

[xen0n]

There's now a mgo-like library wrapping the official mongo-driver called qmgo. I have successfully migrated our production systems from mgo to it with minimal fuss. Basically you pass context everywhere and rename a few methods.

Disclaimer: I work for Qiniu and am a contributor of that project.

[jiangz222]

I use a lot of mgo in my projects，I want to Implement mgo interface via mongo-go-driver。

Try qmgo, transfer to qmgo from mgo with minimal code changes