Create drush command for mongodb sync similar to sql:sync

I'm not sure what that command would actually do, or what it could do better than the CLI tools provided by MongoDB.

Can you describe what problem you are actually trying to solve, that is not already solved by existing official tools ?

@fgm Yes, sorry if this is already possible, but I haven't found anything like it.
I want to be able to sync remote mongo database.

So for example I have drush alias called "@dev"
I want to be able to copy database to my current environment "@self" from "@dev".

So exactly like default drush sql:sync but for mongodb:
https://www.drush.org/12.x/commands/sql_sync/

In most cases, you will be better served (faster, less server load) using mongodump on the first DB and mongorestore to the second one: that is Go optimized code, tuned by MongoDB themselves, while anything in Drush will be slower due to the use of PHP, and likely less portable across MongoDB and Drupal versions.

See https://www.mongodb.com/docs/database-tools/mongodump/#std-label-mongodu... for how to use those commands.

The legacy copydb and its mongosh helper db.copyDatabase() have been removed since MongoDB 4.2, so three major versions ago, to drive all users to the use of mongodump / mongorestore.

At this point, this looks like a "won't fix". Do you have any specific reasons why mongodump would not work for you mongorestore ?

Not sure about portability part. But it would be definitely more performant.

Just for consistency I want to be able to define aliases once (in drush).

Also most php container images don't have Mongo Database tools installed.

Thanks anyway.

Yeah: because the dbcopy command no longer exists in current MongoDB versions anyway, actually implementing that feature in PHP will just run the CLI tools underneath, so they would have to be available anyway.

Regarding containers, the default mongo includes the CLI tools anyway, so you would have to use a custom trimmed image not to have them: https://hub.docker.com/layers/library/mongo/7.0.5/images/sha256-bd74130e...

@fgm Yes it will most probably have to run CLI tools underneath, not sure if other approach would make sense as I mentioned in base issue description. So drush would be here just for easier alias management.

I can put commands here once I am done with it, but based on this seems like you wont change your mind :)

You are right: in order to keep that package maintainable, I limit its scope fairly strictly, and duplicating upstream features is not part of the plan.

However there is a part of your idea which is something that might go in as it is really part of the Drupal bits instead of upstream Mongo, and that is a way to show the resolved aliases, which could be useful as sometimes people build their settings incorrectly, and could help build shell scripts by providing the names from the aliases.

Possibly something like "drush mongo:alias []" returning the description for the alias as resolved, if one is passed, and the JSON list of resolved aliases if none is passed. That could then be passed to jq to filter for the desired info in a shell script.

@fgm Maybe I wasn't clear on which aliases I talking about, but by aliases I mean drush site alias that has nothing to do with mongo database aliases.

But anyway, having something like drush mongo:alias or drush mongo:connection_string would help.

But still to achieve what I desire I would also need to parse ssh connection from desired drush site alias, which I don't want to do since it is in drush out of box.

I love bash(shell), don't get me wrong, after all I need this to use in internal project build bash script, but I want to keep this part of functionality in drush.

I see. At this point, I think the best course is

• you build that command
• you set it up as a d.o. sandbox project, marked as in the MongoDB ecosystem
• I add it to a new "ecosystem" section on the MongoDB project page
• after a couple of months if we see it gets significant use, we can always reconsider incorporating it in the main project

How do you feel about it ?

Sounds like a good plan

Any news ? Maybe a sandbox repo I could check ?

@fgm I haven't got time to work on this.
Project that will use this is still not in active development state.
I've just tested if it will work as expected and seems it will.
I will inform you. We will test it first internally.