-
Notifications
You must be signed in to change notification settings - Fork 12
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
Extend the Completable interface methods #46
Comments
Yeah, I guess another options would be to explicitly specify what we know |
I didn't propose that because for example Athena, and I assume others, are schema-less and also the order of the parametes may vary. For example, from wider to narrower a datasource may want to use |
I think a struct may be an OK substitute but I think we may run into the same problem...
I don't like option 2 because it makes it quite hard to understand when implementing the function Option 1 and 3 don't excite me because empty interfaces are just so inconvenient to work with I try to avoid them as much as possible, but it may not be avoidable in this case. This would be a good case for generics in another language. So I'm for either 1 or 3. Probably 1 because at the very least you can define the keys as constants or something. |
yes, a typed struct would only help for adding new parameters without making a breaking change but it would still changes in the library if we want to add a parameter and we wouldn't be able to add custom (non common) parameters.
Okay, let me try with 1. |
The current method for getting a table columns looks like this:
This is not complete since the columns may depend of a schema (e.g. there can be a table
foo
in two schemaspublic
andbar
). But some SQL data sources doesn't have the concept of schema and forcing it may not be the best option.Also, we have an example of a data source that the table / column resolution depends on other parameters (not SQL related). This SQL data source is a database as a service, so it also depends on the database name and the region. To satisfy this for the moment, we have added a new endpoint
/columns-with-details
but that's just a workaround IMO.To satisfy all the different data sources, we will need flexible argument(s) to set the different parameters. If we agree to that we have several options for the function signature:
func Columns(ctx context.Context, options map[string]string) ([]string, error)
func Columns(ctx context.Context, options ...string) ([]string, error)
func Columns(ctx context.Context, options interface{}) ([]string, error)
I would go with the second since it better reflect the variadic nature of the function and all the parameters we foresee are strings. Opinions?
Note that this would be a breaking change.
The text was updated successfully, but these errors were encountered: