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

Adding SET statement for configuration management #1180

Merged
merged 13 commits into from
Sep 23, 2023

Conversation

hershd23
Copy link
Contributor

@hershd23 hershd23 commented Sep 21, 2023

Added

  • Parser for SET statement
  • Class for SET statement
  • StatementType.SET to parser.types

	modified:   evadb/parser/evadb.lark
	modified:   evadb/parser/evadb.lark
Added class for set_statement
	new file:   evadb/parser/set_statement.py
Added SET to statement_types
	modified:   evadb/parser/types.py
statement
	modified:   evadb/parser/evadb.lark
	modified:   evadb/parser/lark_visitor/__init__.py
	new file:   evadb/parser/lark_visitor/_set_statement.py
	modified:   evadb/executor/plan_executor.py
	new file:   evadb/executor/set_executor.py
Added an optimizer for set queries
	modified:   evadb/optimizer/operators.py
	modified:   evadb/optimizer/statement_to_opr_converter.py
Added a plan for set queries
	new file:   evadb/plan_nodes/set_plan.py
	modified:   evadb/plan_nodes/types.py
@hershd23
Copy link
Contributor Author

Hi @jiashenC @xzdandy @gaurav274 adding you as reviewers. This PR is up for an early review

Have added parser, executor, plan and optimizer for SET queries please give them a look.

I see that the we send config with a category param as well. Wanted to make sure if we wanted to continue with that design, since in the example given duckDB did not have that
https://duckdb.org/docs/sql/configuration.html

Will take up SELECT command for displaying configs and tests for this in separate PRs

Copy link
Member

@jiashenC jiashenC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! The design looks good to me. Just some clarification questions

  1. Are we going to universally use string type for config value? This can be easier if we want to store those values in the catalog.
  2. Are we going to persist configuration values and those changes will be part of this PR?

@hershd23
Copy link
Contributor Author

hershd23 commented Sep 21, 2023

For 1, I am not very sure since there is an example where we are adding tuples in config_value. Example -

cursor._evadb.config.update_value("executor", "gpu_ids", [0,1])
.

We could serialize-deserialize but that would also require us saving the type.

For 2, I do not think we are. This is more about about creating the query to manage configurations. Persisting to disk can be taken as a natural extension of this problem once done.

evadb/parser/evadb.lark Outdated Show resolved Hide resolved
@xzdandy
Copy link
Collaborator

xzdandy commented Sep 21, 2023

Great work. Looks good to me overall. Let's add a test cases to verify the config value has been changed.

@xzdandy xzdandy linked an issue Sep 21, 2023 that may be closed by this pull request
5 tasks
@xzdandy xzdandy added the Feature Request ✨ New feature or request label Sep 21, 2023
@hershd23
Copy link
Contributor Author

hershd23 commented Sep 22, 2023

Hi @jiashenC, @xzdandy and @gaurav274. Was confused about this and wanted to run this by you.

In eva the current way we do configs is by three params

  1. Category
  2. config_key
  3. config_value

This PR captures config_key and config_value but not category. For that do we want to change the method to include category or not?

If we change category then our query looks something like

SET EXECUTOR GPU_IDS = [0, 1]

OR

SET GPU_IDS = [0, 1] IN EXECUTOR

or something that involves passing the category as well.

OR

Since DuckDB and Postgres like @xzdandy added they just have key and value. No concept of category. That is the way query is currently implemented. This seems to be the common way DBs add configs.

SET GPU_IDS = [0, 1]

What do you say?

@jiashenC
Copy link
Member

jiashenC commented Sep 22, 2023

Hi @jiashenC, @xzdandy and @gaurav274. Was confused about this and wanted to run this by you.

In eva the current way we do configs is by three params

1. Category

2. config_key

3. config_value

This PR captures config_key and config_value but not category. For that do we want to change the method to include category or not?

If we change category then our query looks something like

SET EXECUTOR GPU_IDS = [0, 1]

OR

SET GPU_IDS = [0, 1] IN EXECUTOR

or something that involved passing the category as well.

OR

Since DuckDB and Postgres like @xzdandy added they just have key and value. No concept of category. That is the way query is currently implemented. This seems to be the common way DBs add configs.

SET GPU_IDS = [0, 1]

What do you say?

I vote for going with Postgres's approach.

@jarulraj
Copy link
Member

Let's ditch category

https://www.postgresql.org/docs/current/config-setting.html#CONFIG-SETTING-SQL

@xzdandy xzdandy added this to the v0.3.7 milestone Sep 22, 2023
@xzdandy xzdandy added User Experience and removed Feature Request ✨ New feature or request labels Sep 22, 2023
	modified:   evadb/executor/set_executor.py
Since we use a comparitor in the LOGICAL OPERTATORS on LOGICAL
DELIMITER, we have to put LOGICALSET over LOGICALDELIMITER
	modified:   evadb/optimizer/operators.py
Fixed typo (private data member)
	modified:   evadb/optimizer/statement_to_opr_converter.py
Added a construct for TO
	modified:   evadb/parser/evadb.lark
Make class variables as properties
	modified:   evadb/parser/set_statement.py
Added a short integration test for end to end query testing
	new file:   test/integration_tests/short/test_set_executor.py
Added a unit test for SET query parsing
	modified:   test/unit_tests/parser/test_parser.py
@hershd23 hershd23 mentioned this pull request Sep 22, 2023
5 tasks
	modified:   evadb/executor/plan_executor.py
	modified:   evadb/executor/set_executor.py
	modified:   evadb/parser/utils.py
	modified:   test/unit_tests/parser/test_parser.py
	modified:   evadb/executor/set_executor.py
	modified:   evadb/plan_nodes/set_plan.py
@hershd23
Copy link
Contributor Author

@gaurav274 @xzdandy @jiashenC this is up for review

Copy link
Collaborator

@xzdandy xzdandy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work. Nits: fix the linter.

@hershd23
Copy link
Contributor Author

Done @xzdandy

@hershd23
Copy link
Contributor Author

Since I am not using the plan classes now, I will remove them

skipping those
	modified:   evadb/executor/set_executor.py
	modified:   evadb/optimizer/operators.py
	modified:   evadb/optimizer/statement_to_opr_converter.py
	deleted:    evadb/plan_nodes/set_plan.py
	modified:   evadb/plan_nodes/types.py
	modified:   test/unit_tests/optimizer/test_statement_to_opr_converter.py
@xzdandy xzdandy removed a link to an issue Sep 23, 2023
5 tasks
@xzdandy xzdandy merged commit 27e2635 into georgia-tech-db:staging Sep 23, 2023
@xzdandy xzdandy linked an issue Sep 23, 2023 that may be closed by this pull request
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Configuration Manager Redesign
4 participants