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.
On 18 Nov., 01:31, bingomanatee <poppin.fre...@gmail.com> wrote:
> 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 ? :)
