CEXT-5230: Releasing aio app db cli commands

[pdohogne-magento]

Description

Committing aio app db commands to main

Related Issue

CEXT-5230: Deploy CLI DB App to Staging

Motivation and Context

Release aio app db commands

How Has This Been Tested?

Unit and manual tests, see PRs #12 - #26

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nofuss]

• aliases (edited my previous comment): collection|col index|ind document|doc

agreed - collection can get tiring to type

• QUESTION? does it make sense to infer the current collection? so that we don't need to pass COLLECTION as an argument (especially for all the doc commands) we could use a flag instead --collection to overwrite the current one in context. it could be set via an env variable AIO_DB_COLLECTION

I think this would be a stretch. It would be comparable to having a "current table" in SQL, and that is hard to imagine. I honestly think adding the idea of a "current collection" would be more confusing than convenient.

• is aio app db show collections an alias for aio app db collection list?

yes. I included show collections mainly because it is so common in mongosh that I can imagine people typing it out of instinct.

[moritzraho]

I think this would be a stretch. It would be comparable to having a "current table" in SQL, and that is hard to imagine. I honestly think adding the idea of a "current collection" would be more confusing than convenient.

sounds good 🤝

[nofuss]

My take on defaults for one vs many document operations:

• find: default to many
• all others: default to one (safety first!)

Make sense for everybody?

[moritzraho]

Make sense for everybody?

makes sense, so you would control many insert/deletes/.. through a flag (--many) + multiple args?

[nofuss]

Make sense for everybody?

makes sense, so you would control many insert/deletes/.. through a flag (--many) + multiple args?

The --many flag is more about how many documents are affected. Both updateOne and updateMany, for example, have basically the same args, but updateMany will update however many documents are matched by the filter, but updateOne will update one and only one document, even if the filter matches multiple documents.

As for insert, we could make that simpler. If one document is provided, use insertOne, if a list of documents is provided, insertMany (no flag needed).

[pdohogne-magento]

Luckily combining find and findOne just means removing the latter, as finding only a single document can be achieved by passing --limit 1 to the find command 😄

[moritzraho]

cleaan!!

lgtm :)
just one small comment

[moritzraho]

should this take a many flag?

[pdohogne-magento]

At Manik's request we are not including deleteMany functionality in the CLI

[AjazSumaiya]

nice work @pdohogne-magento , looks good

[purplecabbage]

The version should be modified by an explicit release job. We will need to manage the pre version, and the dependency in a branch until we go GA