MongoDB 1.7.3 (unstable) Released

[Eliot Horowitz]

MongoDB 1.7.3 is now available for testing.
This is part of the 1.7 development series which is not intended for
production use.
1.8 will be the culmination of the 1.7 series

Notable Changes:
- initial covered index support
- distinct can use data from indexes when possible
- map/reduce can merge or reduce results into an existing collection
- mongod tracks and mongostat displays network usage
- sharding stability improvements

Downloads: http://www.mongodb.org/downloads
Change Log: http://jira.mongodb.org/browse/SERVER/fixforversion/10195

As always, please let us know of any issues,
-Eliot

[kevin]

please can we get this in the next one!
http://jira.mongodb.org/browse/SERVER-991

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Andrew Kempe]

I second this... if I could vote more than once, I’d do that too :)

[bingomanatee]

This feels like slippery slope stuff here - once you move past simple
i/o for key/value sets you end up coding applications in the model and
committing and maintaining things in the Mongo stack that are best
left and easily accomplished with JavaScript or server side code.

If you are going to clip an array(stack) to a maximum size, why not
write input filters in MongoDB? or allow arrays of arrays and limit
the size of the stack to the size of the sum of the members'
elements?

Why not write model-centric schemas with defaults?

I like mongo the way I like my women - fast, stupid and numerous. If
it starts doing too much on its own then what will we do for a
living ? :)

[jannick]

Assuming that the array-length-limit is supplied by the application
code (ie. no schema or metadata in mongo) I fail to see how this is
different from the atomic update operations we already have access to.
They could all be emulated using findAndModify + a versioning field,
but by having them as operations we get:
- Simpler programming model
- Better performance for some use cases, as the record doesn't have
to be sent to the app, and we don't have to do optimistic concurrency
with retries.

Given the document "hard" size-limit, a lot of apps have to either
prey the most extreme edge-cases never shows up, or switch to a more
complex and lower performing approach in order to handle the "max
entries" constraint themselves.