Giters

fsprojects / FSharp.AWS.DynamoDB

F# wrapper API for AWS DynamoDB

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

support for TTL

thomasd3 opened this issue · comments

commented

Any plans to implement the TimeToLive feature of DynamoDB?

commented

@thomasd3 do you still have a need for it? Would you consider submitting a PR?

I've done zero research - it that simply an option when creating? I see based on this article that there are two levels - item level and table level. Do you have a specific need for one or the other in your context ?

The creation lifecycle will receive some love in #43; Perhaps providing a ?customize : CreateTableRequest -> unit option might be sufficient if you want to do it at table level? Would you need to be able to UpdateTable to reconfigure it?

At item level, I suspect that it can be specified by providing a field with the well-known name on your record without any code changes, but there may be some rough edges (again, if you or anyone has specific ideas or requirements, please feel free to jump in)

commented

@bartelink we've totally dropped the use of DynamoDB in our system, so I haven't touched that system in many months now.

commented

Thanks for the update - that's no problem

With the way the Verify/Initialize/Provision APIs in #43 now expose an optional customize callback will unblock anyone with TTL requirements as:

  1. any CreateTableRequest customizations can be applied as necessary
  2. I believe the TTL field at table level can be provided by defining a record field that aligns with the naming and types suggested by the article

Therefore I have updated that PR to close this one - let me know if you disagree @samritchie

If anyone encounters any requirements not served, please feel free to discuss here and/or raise a new specific issue with more details on the exact needs.

commented

I'd expect TTL to be defined using an attribute on the appropriate record field, this is more consistent with the way we define GSIs etc. It’s going to involve some work at the pickle layer as it needs to be stored as epoch time rather than the string we convert DateTimeOffsets to by default - this is going to be very intolerant of adding/removing the TTL attribute from fields.

commented

I'll reopen this one pending a reasonable design. As I see it the options are:

  1. Do nothing, allow people to define TTL themselves and just configure a matching numeric attribute in the record
  2. Add a TTL field attribute that only supports numeric data types and requires users to convert to epoch time themselves
  3. Add a TTL field attribute that supports .NET date types and automatically translates to epoch time, bearing in mind this will break deserialisation if the attribute is added to/removed from an existing field in a table
  4. The above, but with some sort of fallback on deserialisation (eg transparently unpickle a numeric type if found).
  5. Define a standalone TtlExpiry type