Skip to content
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

support for TTL #35

Open
thomasd3 opened this issue Mar 16, 2021 · 5 comments · Fixed by #43
Open

support for TTL #35

thomasd3 opened this issue Mar 16, 2021 · 5 comments · Fixed by #43
Assignees

Comments

@thomasd3
Copy link

thomasd3 commented Mar 16, 2021

Any plans to implement the TimeToLive feature of DynamoDB?

@samritchie samritchie self-assigned this Apr 21, 2021
@bartelink
Copy link
Member

bartelink commented Apr 4, 2022

@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)

@thomasd3
Copy link
Author

thomasd3 commented Apr 4, 2022

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

@bartelink
Copy link
Member

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.

@samritchie
Copy link
Collaborator

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.

@samritchie
Copy link
Collaborator

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

@samritchie samritchie reopened this Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants