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
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)?
The text was updated successfully, but these errors were encountered:
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.
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.
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)?
The text was updated successfully, but these errors were encountered: