Can we have the restore feature? about cognito-backup HOT 9 CLOSED

I have now implemented restore in cognito-backup, code based on your fork. Added some improvements too.
Upgrade to v1.2.0 to try it out. I only did a basic test.

from cognito-backup.

We've created a tool to at least take the output of cognito-backup, and map into into the .csv format AWS wants for importing users.

It's not a full "restore", but a step closer: https://github.com/Collaborne/cognito-restore / https://www.npmjs.com/package/cognito-restore

from cognito-backup.

@ankon

I fork this repo and add the restore feature directly (without csv file) in my repo cognito-tool

Can you test it and let me now if everything works fine?

# install cognito-tool
npm install -g cognito-tool

# backup from an exist user pool
cognito-tool backup-users <old_user_pool_id>
cat <old_user_pool_id>.json

# create a new cognito user pool

# restore 
cognito-tool restore <new_user_pool_id> --file <old_user_pool_id>.json

https://www.npmjs.com/package/cognito-tool

from cognito-backup.

@ozbillwang why not make a pull request if you forked and modified?

from cognito-backup.

First the npm package name cognito-backup can't be used by anyone else in npmjs.com. So I have to test it with a new name.

Second, I am going to add more features, not only for backup and restore. So the name cognito-backup is not suitable any more. I set the new name to cognito-tool that I can fully control the build and deployment.

Do you mean I have to fork not build a new repo? I don't think this is compulsory, that I keep the LICENSE in my repo

from cognito-backup.

First the npm package name cognito-backup can't be used by anyone else in npmjs.com. So I have to test it with a new name.

Having something on npmjs shouldnt be a dependency for testing. You can always npm install from a git repo and whether you're using CI or local testing, it should work the same as far as testing is concerned.

Second, I am going to add more features, not only for backup and restore. So I name the new name to cognito-tool that I can fully control the build and deployment.

While you have every right to go down this path, my opinion with this type of thing is to pull request into the upstream what is relevant to the upstream/this-repo (ie features directly related to backup operations) and in your separate project, simply include this one as a dependency.

I hope this doesn't come across as antagonizing, that's not the intent. I'm simply expressing what I think is the right way when it comes to being a proponent of open source projects and their maintainers. Granted if @mifi doesn't care to keep this project up, then sure, it would be good to pass the reins on.

Just my 2c.

from cognito-backup.

@defionscode

I re-read the LICENSE , that there is no restrict role that I have to fork it.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

I understand your meaning, I did a lot of fork and PRs as well. But for this repo, I don't think fork is suitable, which I need take the control for new codes I added and I am not going to raise PR to upstream.

from cognito-backup.

If you read above, I said "While you have every right to go down this path..." Perhaps you didnt understand what I wrote, in which case that is my fault for not being clear enough. Regardless of what you do, I wish you the best.

from cognito-backup.

Thanks. We shouldn't spend time on this topic more than the features. If you have suggestions about the functions you want to add, or help to add codes and raise PR, let me know.

from cognito-backup.