CreateTable fails when using TTL field with local-dynamo about dynamo-types HOT 5 CLOSED

yes I (and Vingle team) and aware of this issue - kind of tricky since it's just that local-dynamo does not support TTL (which they should honeslty :( )
currently, we're doing work around like

  @Decorator.Attribute({ name: "ttl", timeToLive: process.env.MODEL_STAGE === "production" ? true : undefined })
  public ttl: number;

which i have to admit kind of dumb.
but also, since dynamo-types is independant from local-dynamo, adding codes for handling that specific case is somewhat annoying. (like you mentioned)

I can make a simple try-catch wrapper to hijack the UnknownOperationException error and throw a custom error like "This dynamoDB doesn't seem to support TTL". within creatable similar to what you suggested. how do you think about that?

from dynamo-types.

It's tough because if you trap the error but throw another error instead, then you're not really any better off. I was actually going to see what options there were for detecting if local-dynamo is in use, to use in an if/then test in create table, but I'm not sure there is anything standard. Even testing the URL is kind of hacky. I don't know if there's any command that can be send to dynamodb that basically says "identify yourself" that would give a response that it's local vs real Dynamo and therefore could be used, kind of like asking MySQL to report its version number.

I actually think your workaround of just testing for environment in the table class itself is cleaner than the try/catch in the unit test. I don't know if any operations would throw the UnknownOperationException that I might be ignoring whe I shouldn't when doing it that way.

I'll keep poking and maybe do a PR if I can find something, I've been wanting to submit some things anyway since I'm using the package. (Also on a side note, the link on npmjs to this package no longer has the Github.com link back to this site.)

from dynamo-types.

ok thanks :) I remember I had the same issue and took me a while to find out TTL was an issue when I was testing with local-dynamo. even though wrapping that error wouldn't really fix the issue, that might help developers to know that's the problem - (which really should be done by local-dynamo, but whatever)
whole problems comes down to the fact local-dynamo itself is very hacky. well...
i'll keep this issue open for a while, let me know. if there isn't really a way to go around this, i'm really ok with wrapping that error and at least let developers know that's the issue, not the random aws-sdk error :)

from dynamo-types.

Starting DynamoDB Local v1.11.119 (2017-04-13), It supports TTL. but unfortunately, Current local-dynamo latest release was bundled with DynamoDB Local v1.1.86 (2017-01-24).

Here is short release note summary (from latest version DynamoDB Local)
(Maven repository link)

Release Notes
-----------------------------
2019-02-06 (1.11.477)

  * Bugfixes

2019-02-04 (1.11.475)

  * Add on-demand implementation
  * Add support for 20 GSIs (up from 5)
  * Add transaction API implementation
  * Update AWS SDK for Java to version 1.11.475

2017-04-13 (1.11.119)

  * Add TTL implementation
  * Update AWS SDK for Java to version 1.11.119

2017-01-24 (1.11.86)

  * Implement waiters() method in LocalDynamoDBClient
  * Update AWS SDK for Java to version 1.11.86
  * Enable WARN logging for SQLite

2016-05-17_1.0

  * Bug fix for Query validation preventing primary key attributes in query filter expressions

The local-dynamo package seems unmaintained status so we won't able to use TTL feature until local-dynamo gets a new update to bundle new version of DynamoDB Local release.
(Latest release of DynamoDB Local supports Transaction also)

Currently there are two choices:

1. Fork local-dynamo and maintain that from our side
2. Manually download DynamoDB Local Jar package from AWS and running them as custom npm script

from dynamo-types.

Now we dropped local-dynamo package usage. I highly recommend you to use dynamodb-local as separately. Now dynamo-types CI also uses dynamodb-local as Docker container.

For example (using docker):

$ # create dynamodb service
$ docker create --name dynamodb -p 8000:8000 --health-cmd "curl --fail http://127.0.0.1:8000/shell/ || exit 1" --health-interval 10s --health-timeout 5s --health-retries 5 amazon/dynamodb-local
$ # then start service
$ docker start dynamodb

from dynamo-types.