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: support async getters/setters #397

Open
nhomble opened this issue Jun 27, 2024 · 3 comments
Open

feature: support async getters/setters #397

nhomble opened this issue Jun 27, 2024 · 3 comments

Comments

@nhomble
Copy link

nhomble commented Jun 27, 2024

Could electrodb be extended to support get/set hooks (prewrite and postread) to allow async functions?

Since the async part of it implies some more latency, I think it would be reasonable to only call these transformations once per write or read. Maybe to avoid confusion with existing get/set, we could just call these transformers or converters.

A common use case would be to transform certain fields in the schema as requiring a common encryption or hashing transformation prior to write. Conversely on the read, a similar transformation would be needed to decrypt the data.

The async part of it comes in when you have more complicated key retrieval strategies such that you need to retrieve the key per payload.

@zirkelc
Copy link
Contributor

zirkelc commented Jun 28, 2024

I have a similar requirement, I think, where I want to combine multiple primitive fields (string/number/boolean) into one single object (map) after it was read from the database. I assume it's a common issue to break apart an object into it's primitive constituents to be able to use these on primary and secondary indexes. Therefore, it would be very useful to have getters and setter also on the entity-level rather than just on attribute-level.

@tywalch
Copy link
Owner

tywalch commented Jul 20, 2024

@nhomble I have also considered this, namely something like read and write callback which would accept an async function and be invoked only on uses of .go() and after all other model transformations. I'll keep this issue open to keep track of this work. This work would be non-trivial (the item transformation flow is complex and currently synchronous) so I can't say when I will be able to prioritize it and there are currently other items in front of it.

@zirkelc An item level getter/setter would most likely to come as an execution option to .go({ read, write }) because it will have the smallest lift from an implementation and typing perspective.

@hongkongkiwi
Copy link

Could I add my vote for async validation? :)

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

No branches or pull requests

4 participants