You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
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.
The text was updated successfully, but these errors were encountered: