[ANN] mgo r2012.03.04

[Gustavo Niemeyer]

Greetings,

Just tagged a release of the mgo MongoDB driver for Go
with some minor updates.

Project details are available at:

http://labix.org/mgo

The following changes were made in this release:

- Fields using a `bson:"-"` tag are now ignored.
Thanks to Aaron Raddon for pointing out the missing
feature.

- Implemented unmarshaling of BSON lists onto Go arrays.
For an array to be successfully unmarshalled, it must
match exactly the size of the BSON list. Problem
reported by John Asmuth.

- The stock url.URL type is now marshalled and unmarshalled
by the bson package as a string.

- Clarified documentation for EnsureIndex to make it clear
that MongoDB does NOT return immediately even if Background
is set to true. The setting affects the ability of other
sessions and connections to use the given collection while
the index is being built.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.

[Paddy Foran]

Hi Gustavo,

Thanks for the new release!

Is there any way to make the url.URL type continue to marshal/unmarshal as a struct? I actually preferred having it split into its component parts.

Thanks,

Paddy

[Gustavo Niemeyer]

Hey Paddy,

On Sun, Mar 4, 2012 at 12:42, Paddy Foran <foran...@gmail.com> wrote:
> Thanks for the new release!

You're very welcome.

> Is there any way to make the url.URL type continue to marshal/unmarshal as a
> struct? I actually preferred having it split into its component parts.

It surprises me a bit that you find marshaling raw URLs convenient.
Note that something like "http://example.com" will be stored in the
database as:

{"scheme": "http", "host": "example.com", "path": "", "user": nil,
"opaque": false, "rawquery": "", "fragment": ""}

Besides the fact that this feels a bit inconvenient both for querying
and in terms of the disproportional storage space required for it, the
"user" field will never marshal correctly, which is why I felt
comfortable with the change.

In case you do want to marshal the individual fields, I suggest
creating a type based on URL that has a custom GetBSON method.

Does that sound ok or is it too much of a hassle?

[Paddy Foran]

On Sun, Mar 4, 2012 at 11:06 AM, Gustavo Niemeyer <gus...@niemeyer.net> wrote: 

> Is there any way to make the url.URL type continue to marshal/unmarshal as a

> struct? I actually preferred having it split into its component parts.

It surprises me a bit that you find marshaling raw URLs convenient.
Note that something like "http://example.com" will be stored in the
database as:

{"scheme": "http", "host": "example.com", "path": "", "user": nil,
"opaque": false, "rawquery": "", "fragment": ""}

That is, actually, my intended behaviour. :)

Besides the fact that this feels a bit inconvenient both for querying
and in terms of the disproportional storage space required for it, the
"user" field will never marshal correctly, which is why I felt
comfortable with the change.

For me, it's actually *more* convenient for querying. I never want to query by a URL I have stored in the database. I do, for statistical purposes, sometimes want to query by the host, scheme, or path, though. I'm sure I could do this with a regular string in the database, but that would require me reading something and actually learning a little bit about the database I'm using. ;)

In case you do want to marshal the individual fields, I suggest
creating a type based on URL that has a custom GetBSON method.

Does that sound ok or is it too much of a hassle?

That's a perfectly adequate substitute. Not as simple, but it's a serviceable workaround. In all honesty, I'll probably end up just learning a bit more about Mongo and doing this the "right" way, instead of taking a shortcut that bloats my database size.

Thanks again.

[Gustavo Niemeyer]

On Sun, Mar 4, 2012 at 13:46, Paddy Foran <foran...@gmail.com> wrote:
> For me, it's actually *more* convenient for querying. I never want to query
> by a URL I have stored in the database. I do, for statistical purposes,
> sometimes want to query by the host, scheme, or path, though. I'm sure I

If you need fast queries by path, it may justify storing it in an
expanded form, otherwise you won't benefit from indexing. For scheme
and host (given a reduced set of schemes), you can do that efficiently
with a single field.