When syncing to/from dynamodb global tables, the diffing should ignore the additional global-table related fields.

I technically haven't tested this, simply looking at the code trying to figure out if this would work for global table replication, I think this would fail. I think the diffing would need to ignore any of the aws: prefixed fields. For reference: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_HowItWorks.html

Example

{
  "aws:rep:deleting": {
    "BOOL": false
  },
  "aws:rep:updateregion": {
    "S": "us-west-2"
  },
  "aws:rep:updatetime": {
    "N": "1542916362.440001"
  },
  "created_on": {
    "N": "1539334691"
  },
  "id": {
    "S": "CatalogId-B2ZyEvviYV5CdgBwjbAN6"
  },
  "key": {
    "S": "catalog.autocare_webservice_enabled"
  },
  "updated_on": {
    "N": "1539334691"
  },
  "value": {
    "BOOL": false
  }
}

The work around would simply be to specifically use your --ignore-att flags, but the new "official" attributes should probably be added to the default list. (I'm not sure if this is best handled in the cli.js or part of the Synchronizer.js in the omit function?

I'm having issues understanding how to use this as a library. I'm able to get it to work using the cli but when I try to use it as a lib it doesn't seem to find any differences.
This is what I get back when using as a Lib:

{ 'us-east-1:my-slave-table': { extra: 0, sameAs: 0, differing: 0, missing: 0 } }

exports.handler = async () => {
      const sync = new Synchronizer(
        { region: 'us-east-1', name: 'my-master-table' },
        [{ region: 'us-east-1', name: 'my-slave-table' }],
        {
          writeMissing: true,
          writeDiffering: true
        }
      );
      console.log(sync._stats)
};

And using CLI:

Now that #16 has been merged in it'd be great to configure automated builds on Docker Hub so that people could take advantage of pre-built Docker images.
This shouldn't involve much more than signing up for a Docker Hub account and giving it permissions to access this organization's Github repositories.

Especially when copying from a prod table to a brand new table, the "ERROR: ..." scrolling by gets a bit distracting.

It might be nice to have a --summary or --log-level or ??? flag for tweaking output and minimizing console logging - especially if this gets crontab'ed.

Use Case

At current, it is not possible to synchronize from a remote DynamoDB to a local instance (e.g. running the local emulator or Docker image) due to how the client connection is constructed.

This functionality can be really useful to create a local copy of a remote DDB for testing and development purposes (or possibly even in a CI pipeline).

Proposal

Reuse the existing command line flag --slave-profile to accept a URL endpoint for the localhost when running in local mode.

This will allow synchronization between a remote DynamoDB instance and a local DynamoDB instance.

Key Changes

• Update the argument processing to detect the local endpoint
• Update the client connection to use the local endpoint
• Update documentation on how to use the local mode.

I haven't dug into this, but I got this error on my first run at the end (and at the end of a 2nd run too)

https://github.com/silvermine/dynamodb-table-sync/blob/master/src/Synchronizer.js#L527

    at /c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/src/Synchronizer.js:527:22
    at _fulfilled (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:854:54)
    at self.promiseDispatch.done (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:883:30)
    at Promise.promise.promiseDispatch (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:816:13)
    at /c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:624:44
    at runSingle (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:137:13)
    at flush (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:125:13)
    at _combinedTickCallback (internal/process/next_tick.js:132:7)
    at process._tickDomainCallback (internal/process/next_tick.js:219:9) Error: ERROR: unprocessed keys in batchGet
    at /c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/src/Synchronizer.js:527:22
    at _fulfilled (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:854:54)
    at self.promiseDispatch.done (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:883:30)
    at Promise.promise.promiseDispatch (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:816:13)
    at /c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:624:44
    at runSingle (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:137:13)
    at flush (/c/Users/Eric Peters/.npm-packages/lib/node_modules/silvermine-dynamodb-table-sync/node_modules/q/q.js:125:13)
    at _combinedTickCallback (internal/process/next_tick.js:132:7)
    at process._tickDomainCallback (internal/process/next_tick.js:219:9)```