[ANN] mgo r2013.04.05

94 views
Skip to first unread message

Gustavo Niemeyer

unread,
Apr 5, 2013, 7:00:27 PM4/5/13
to golan...@googlegroups.com, mongod...@googlegroups.com, mgo-...@googlegroups.com
Greetings,

Release r2013.04.05 of the mgo MongoDB driver for Go is out
with several fixes and improvements.

Details about the driver may be found in its web page:

http://labix.org/mgo

The following changes were made in this release:

- Fixed test case to adapt to minor differences in MongoDB 2.4. All
of the test suite works with 2.4, and continues to work with
earlier versions.

- New Iter.Close method. Close kills the server cursor used by the
iterator, if any, and returns nil if no errors happened during
iteration, or the actual error otherwise.

Server cursors are automatically closed at the end of an iteration,
which means close will do nothing unless the iteration was
interrupted before the server finished sending results to the
driver. If Close is not called in such a situation, the cursor
will remain available at the server until the default cursor
timeout period is reached. No further problems arise.

More details about the behavior at:

http://labix.org/v2/mgo#Iter.Close

- New Database.UpsertUser method and accompanying constants and types
to handle the new role-based permissions introduced 2.4+. The method
Database.AddUser still works in new databases that haven't explicitly
disabled the old user document format, but should be replaced as it
will eventually be dropped.

More details about the method and feature at:

http://labix.org/v2/mgo#Database.UpsertUser

- Fixed concurrency issue when acquiring socket, detected in
collaboration with Roger Peppe.

- Fixed race condition in the machine id initalization performed
during the first call to bson.ObjectId, provided by Roger Peppe.

- Improve IsDup so it handles all known variations of index key
duplication, this time via server code inspection. Problem
reported by Evan Shaw.

- Add Query.LogReplay method, as requested by Daniel Gottlieb.

- Clarified documentation of GridFS.Open* methods to mention
these files are for reading only, as suggested by Lars Conrad.

- Allow direct connection to replica set member in unknown state.
Problem reported by Sam Helman.

- Added test case to confirm authentication works on sharded setups,
including in harsh cases such as a lost primary. Scenario suggested
by Travis Reeder.

- The *Session values have lost the use of SetFinalizer. This helps
the garbage collector to free these values more timely, in exchange
for not trying to help with broken code that isn't closing sessions.


gustavo @ http://niemeyer.net

Gustavo Niemeyer

unread,
Apr 6, 2013, 2:30:26 PM4/6/13
to Rémy Oudompheng, golan...@googlegroups.com, mgo-...@googlegroups.com, mongod...@googlegroups.com
Hey Rémy,

On Apr 6, 2013 4:28 AM, "Rémy Oudompheng" <remyoud...@gmail.com> wrote:
> On 2013/4/6 Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> > - The *Session values have lost the use of SetFinalizer. This helps
> > the garbage collector to free these values more timely, in exchange
> > for not trying to help with broken code that isn't closing sessions.
>
> Can you give more background on this? Finalizers shouldn't delay
> collection of values if you clear them on Close() (then only forgotten
> sessions will interfere).

Sure. The background is that I'm unable to observe finalizers working
for iterators, despite the fact that there were no finalizer cycles.
It's simply never called. There are very rare places in the standard
library that use finalizers, and pretty much no tests. I can see
finalizers working for trivial examples, though, so maybe there are
phantom memory references that would eventually go away, or anything
else really. The fact is that before I can get tests to show sane
behavior with mgo, or find time to sit down and dig further into the
GC implementation to sort out what is really going on, this logic
won't be blindly going in.

Here is a simple example of finalizers not working with mgo:

http://paste.ubuntu.com/5683768/

Here is a simple example of them working with a trivial type:

http://play.golang.org/p/y2ye40aHkH


gustavo @ http://niemeyer.net
Reply all
Reply to author
Forward
0 new messages