vdk-core: add vdk sql-query command #2512
Conversation
antoniivanov
force-pushed
the
person/aivanov/vdk-query-cmd
branch
from
aef3b9e
to
2e0f4e6
Compare
|
It pulls the database from env variables? It would be much nicer if it used the config.ini of the folder you are in? |
No, environment variables are just one source. Similar to how in spring variables can be auto-wired from application properties file or environment variables or system properties. In VDK configuration variable can be auto-wired from env variables, from config.ini file ([vdk] section). With env variables having a higher precedence. And in the future this would be extended. I think most certainly some "global" local config would be needed (like ~/vdk/config in the spirit of ~/.aws/config) but we will see. The tests themselves use environment variables because it's the easiest way to pass the configuration values in the test. But the |
projects/vdk-core/src/vdk/internal/builtin_plugins/connection/query_command_plugin.py
Outdated
Show resolved
Hide resolved
projects/vdk-core/src/vdk/internal/builtin_plugins/connection/query_command_plugin.py
Outdated
Show resolved
Hide resolved
Add vdk sql-query command which will use the same database as the rest of the SQL interfaces (SQL steps, job_input methods) This will replace the per-db commends like vdk impala-query, vdk sqlite-query which are just problematic. This would enable to generalize a lot of the tutorials/examples we have which currently give impression they can be used only wiht "sqlite" (sqlite-query) or trino. Which is primary driver for doing the change now. The command would be used in functional tests where you want to query the default db without needing ot create a job for that. The command for now is hidden (hidden feature) since there are a few TODOs that would be resolved in subsequent PRs.
…query_command_plugin.py
Add vdk sql-query command which will use the same database as the rest of the SQL interfaces (SQL steps, job_input methods) This will replace the per-db commends like vdk impala-query, vdk sqlite-query which are just problematic. This would enable to generalize a lot of the tutorials/examples we have which currently give impression they can be used only wiht "sqlite" (sqlite-query) or trino. Which is primary driver for doing the change now. The command would be used in functional tests where you want to query the default db without needing ot create a job for that. The command for now is hidden (hidden feature) since there are a few TODOs that would be resolved in subsequent PRs.
antoniivanov
force-pushed
the
person/aivanov/vdk-query-cmd
branch
from
c7b71b9
to
e85e969
Compare
This reverts commit 2c3d492. Why This commit causes a circular dependency in the following modules standalone_data_job -> builtin_hook_impl -> query_command_plugin -> standalone_data_job What Revert the commit How was this tested Ran vdk-ipython tests locally, because they caught the circular dependency initially What kind of change is this Bugfix
## Why This reverts commit 2c3d492, because it causes a circular dependency in the following modules standalone_data_job -> builtin_hook_impl -> query_command_plugin -> standalone_data_job ## What Revert the commit ## How was this tested Ran vdk-ipython tests locally, because they caught the circular dependency initially ## What kind of change is this Bugfix Co-authored-by: Dilyan Marinov <mdilyan@vmware.com>
Add vdk sql-query command which will use the same database as the rest of the SQL interfaces (SQL steps, job_input methods)
This will replace the per-db commends like vdk impala-query, vdk sqlite-query which are just problematic.
This would enable to generalize a lot of the tutorials/examples we have which currently give impression they can be used only wiht "sqlite" (sqlite-query) or trino. Which is primary driver for doing the change now.
The command would be used in functional tests where you want to query the default db without needing ot create a job for that.
The command for now is hidden (hidden feature) since there are a few TODOs that would be resolved in subsequent PRs.