<div dir="ltr"><div>tl dr; I'm in favor of fixing mgo but I think we should still avoid them.</div><div><br></div>Note the link that Roger mentioned:<div>  <a href="https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/">https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/</a></div><div><br></div><div>It appears that mongo itself does 2 things that do <b>not</b> play nicely together, regardless of what we do:</div><div><ol><li>subdocument matches care about ordering</li><li>updating a value in a subdocument can reorder its keys</li></ol><div>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.</div></div><div><br></div><div>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".</div><div><br>John</div><div>=:-></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 2:42 AM, Menno Smits <span dir="ltr"><<a href="mailto:menno.smits@canonical.com" target="_blank">menno.smits@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 9 June 2016 at 03:44, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Is it mgo/txn that is internally unmarahalling onto that?</p>
<p dir="ltr">Let's get that fixed at its heart.</p></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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{}? </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Menno</div><div><br></div></font></span></div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>