A cautionary tale - mgo asserts

[John Meinel]

tl dr; I'm in favor of fixing mgo but I think we should still avoid them.

Note the link that Roger mentioned:
  https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/

It appears that mongo itself does 2 things that do *not* play nicely
together, regardless of what we do:

   1. subdocument matches care about ordering
   2. updating a value in a subdocument can reorder its keys

So while it seems it would be good to have mgo/txn handle Asserts correctly
(load objects into a map rather than an ordered slice is good, IMO), we'll
still run into problems if we try to do a Find() by a subdocument match.

It very much feels like subdocument searching/asserting should just be
avoided, as while we might fix X, there is a bug in Y, so it runs into "you
can do it, but only sometimes, and you have to know whether this is one of
those times".

John
=:->

On Thu, Jun 9, 2016 at 2:42 AM, Menno Smits <menno.smits at canonical.com>
wrote:

> On 9 June 2016 at 03:44, Gustavo Niemeyer <gustavo.niemeyer at canonical.com>
> wrote:
>
>> Is it mgo/txn that is internally unmarahalling onto that?
>>
>> Let's get that fixed at its heart.
>>
>
> That would be ideal. The root of the problem is that the Assert, Insert
> and Update fields of txn.Op are of type interface{} and the bson
> unmarshalling uses bson.M for these. This means when a transaction is
> loaded from the txns collection the contents of these fields are loaded
> into bson.M and field ordering is lost.
>
> It looks trivial to change the bson unmarshalling code to default to
> bson.D but naively changing this will likely break existing users of the
> bson package. That's probably not the right solution here. Perhaps
> transactions which are written to/loaded from the database by mgo/txn
> should use a private txn.Op analogue where Assert, Insert and Update are
> bson.D instead of interface{}?
>
> - Menno
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160609/3ef31456/attachment-0001.html>