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

Feature Request: Migration #8

Open
samritchie opened this issue Jan 19, 2017 · 3 comments
Open

Feature Request: Migration #8

samritchie opened this issue Jan 19, 2017 · 3 comments

Comments

@samritchie
Copy link
Collaborator

Probably the biggest want for me is a nice way to handle table 'schema' changes; 9 times out of 10 this is just some way to come up with a default value for a new non-optional field.

A minimal approach would be a TableContext hook that’s invoked when a missing (required) field is encountered, which is passed the untyped row data and should return the new value.

A more substantial migration feature would be storing schema versions in the table and running a schema upgrade function on load.

Both options would benefit from having a 'scanUpgrade' function that pre-emptively loads, upgrades & saves all the rows in the table, so you’ve got the choice between that or lazily upgrading on demand.

Would appreciate any thoughts or suggestions here.

@eiriktsarpalis
Copy link
Member

@samritchie this is already done under the hood using the DefaultValue property for some types in the pickler implementations. However this functionality is intentionally not exposed to the user. It makes an interesting design question to see how this could be exposed to the user for customization without violating type checking and conciseness considerations. Picklers are deliberately implementation detail, however other libraries will happily expose them as part of the public API.

TBH I do not have sufficient bandwidth to work on this. My current employer doesn't deal with AWS, and my previous employer doesn't deal with AWS anymore. So credit-wise the project is currently also lacking a realistic means for developing/testing. I'd be thrilled if other people/companies were interested in stepping in both with offering development time and perhaps sponsoring an AWS subscription to support the CI builds.

@AviAvni
Copy link
Contributor

AviAvni commented Feb 22, 2018

@samritchie @eiriktsarpalis so now we can work on this locally without the need for real dynamodb
@samritchie do you still want this?

@samritchie
Copy link
Collaborator Author

Yes, some sort of migration capability would be awesome. Happy to participate in the design process, I may also be able to help with code if it’s within my abilities.

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

No branches or pull requests

3 participants