Skip to content

Added support for On-Demand Capacity, local DynamoDB instance and rewriting the tables when importing the schema #12

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

antonpkazakov
Copy link

@antonpkazakov antonpkazakov commented Jan 17, 2019

I must also mention @jilykate here, as she contributed at the beginning of this change.

@mifi
Copy link
Owner

mifi commented Jan 27, 2019

Hi! thanks for the PR
Am I right that there are four changes you want?

  1. Set custom endpoint
  2. Delete existing table before import
  3. Supporting some table types that we are not already supporting normal export/import on? (On-Demand Capacity)
  4. Supporting forced rewriting of some attributes in the JSON before importing?

Here's what i'm thinking:

  1. I'm happy with merging
  2. Isn't it better that we implement a separate delete table command in dynamodump? Then the user can call it before calling import if they want to
  3. Need to explain the logic a bit
  4. I'm not sure if this is something that's commonly needed. I think I want to leave it open for feedback from other users.

Maybe you can make a separate PRs for the different features?

@antonpkazakov
Copy link
Author

Yep, these are exactly the 4 changes I'd like to implement. The use case: a local (dev env) import of an existing DynamoDB table with on-demand capacity that doesn't exist locally.
Not sure if it's very common by itself. However, the described features might as well be rather useful separately from each other.

Deleting the table as a separate command may also be useful, I agree. However, what I wanted to implement was deleting the table if needed in the import command (so that we don't care if the table exists while importing and don't even need to check). So I'd say that it would be another, the 5th feature :)

I think separating the features into different PRs could make sense but it would take more time. I'm good with waiting for more feedback from others (maybe we could tag them here to get it earlier), but see more sense in shipping these small features as a bundle, since the bundle is not so big.

Which parts of the logic would you like me to explain more? Would code comments do or the README file modifications are needed in your opinioin?

@titopixelfusion
Copy link

This would be great, I need to import to a local database using the docker image, but there is no way to set the endpoint url

@mifi
Copy link
Owner

mifi commented Feb 26, 2022

Hi again. I just did a rewrite to ESM. If someone wants to address my concerns above and create separate PR's I'm happy to merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants