Issues with mongo and mgo/txn in Juju (Nested Doc Arrays & Mongo Capabilities)


#1

I have come across some issues that I think are worth sharing. This is in regards to serializing and subsequently querying arrays of documents using mongodb in Juju and specifically using mgo/txn.

There are two main points that I would like to highlight here and these are:

  1. The base capabilities of mongodb available to a developer who is hacking on Juju.
  2. The identification and update of a particular document in an array using mgo/txn.

The base capabilities of mongodb available to a developer when hacking on Juju

Currently, with Bionic and Cosmic, Juju is using the package mongodb-server-core which is at mongodb version 3.6. This (and subsequent post mongo 3.2 versions) add features that help with the manipulation of nested document arrays. For example, 3.6 adds the all positions operator ($[]). However, using the ($[]) operator will cause tests that run against versions of mongodb prior to 3.6 to fail. Must we use only those capabilities found in the mongodb version used by the earliest supported version of Juju? If so, is this constraint documented anywhere?

The identification and update of a particular document in an array using mgo/txn

Basically, how does one use the ($) operator with mgo/txn? According to the mongo docs if a user wants to select an item from a document array on which to operate with the ($) operator the user must match an element of a nested array with a query that is grouped with the id of the parent document. Yet, you cannot do this with mgo/txn, the transaction ID field does not allow it, an error occurs if you try this. I cannot easily web search a solution.

I have searched the Juju code base only to find that nested document arrays are seldom used. Is this due to difficulties with the mgo/txn package and the version of Juju as stated above?


#2

Hi @externalreality

was there an agreement on this?

Best,


#3

Juju is still supported on Xenial which uses 3.2. So if there is query that is better you can use 3.6 but you must implement a fallback for 3.2.
I think we even support Trusty which is Mongo 2.4. We have a couple dual purpose code paths for that. (some of the aggregate functions and bit manipulation ops were newer than 2.4 IIRC).

I would probably be ok if juju 2.5 doesn’t support mongo 2.4, but Xenial and 3.2 is going to be supported for another 3 years or so.