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

Decide preferred method for configurations #34

Open
danibishop opened this issue Jan 29, 2019 · 3 comments
Open

Decide preferred method for configurations #34

danibishop opened this issue Jan 29, 2019 · 3 comments

Comments

@danibishop
Copy link

Current version uses a dictionary for datasource configuration and some classes for specific configurations (cache config and per-query config).

Default behavior is enough for basic access but we need to discuss how do we want it to look when specific cases appear. Is the current system a good policy? Do we want something more relaxed (i.e. dictionaries)? More restrictive (i.e. classes)? Parameter based (i.e. **kwargs)?

@josemazo
Copy link
Contributor

josemazo commented Jan 29, 2019

And what about regular paramters for common configuration, like cache and write_query, and use a dict like extra_params?

@danibishop
Copy link
Author

As discussed on 2019.01.30, usual parameters will be passed directly in each method parameters and the rest (less common) will be wrapped in dictionaries.

@danibishop
Copy link
Author

I created a nice class for transparent configuration management. Now, we have a common get_config(key) for caches, datasorces or any class in the future.

It has a default mechanism; when you create a new datasource class (sqlite, for example), you can define a _default_configuration class attribute. The keys there are interpreted as the only ones that can be used and, if no specific one is overwritten, the default value is used.

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