-
Notifications
You must be signed in to change notification settings - Fork 10
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
Introduce extension points for share storage #31
Comments
I'd be interested to work on this. |
This makes a lot of sense! In fact I am hoping, that we can introduce extension points for various components of the sharing server - including the share store. Regarding the naming - while I don't really have a better name, conceptually this should mirror catalogues, such that we can for instance populate the shares and their children from unity catalogue ... I don't really remember the UC APIs, but we may want to have the option to add some more descriptive metadata on top of this. Main application would be to be able to populate UIs o.a. with some information consumers may be interested in around the shared datasets. |
take |
Thanks for the feedback! Let me put up a draft and discuss further from there. |
Not sure if this makes any sense at all, but I just had a thought 😆. What if we more or less mirror the and then add some sort of metadata trait on top of this. This would allow us to re-use the Then again, just a quick thought ... |
I've put up a draft for now. Let me have a think about your suggestions and see how they would fit in here:) |
Currently the Delta Sharing server depends on a postgres database to store information about the defined
shares
,schemas
, andtables
. For a variety of reasons users may want to use a different store. My proposed solution if to introduce aShareStore
trait (open to naming suggestions) and let the app state depend on a concrete implementation defined in a library or user supplied.The text was updated successfully, but these errors were encountered: