Skip to content

chore(log): use loguru instead of logging #713

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

Merged
merged 13 commits into from
Jul 26, 2024
Merged

Conversation

grieve54706
Copy link
Contributor

@grieve54706 grieve54706 commented Jul 24, 2024

Use loguru instead of logging.

It could provide more features, such as associating request logs with a UUID, which is particularly helpful in multi-threaded environments.
Additionally, it allows the entire stack trace to be displayed, including the values of variables.

Add API to control diagnose

Loguru allows log values of variables when diagnose is True. Ref fully-descriptive-exceptions

Remove log level

The main principle of loguru is that there are no levels. By default, everything is printed to sys.stderr. It then allows you to choose to output specific levels to designated files. Please refer to Delgan/loguru#138 (comment)

Use middleware instead of log_dto

By using middleware, we can more elegantly print out the request's parameters and body, and have their logs associated with a UUID. But the request body is not deserialized to the Pydantic model, we need to deserialize the body to JSON and then mask connection information.

Pass Java engine response

Previously, we would only return the Server Internal Error message that occurred when ibis-server called the Java engine to the caller. Now, we will return the error message from the Java engine itself.

Rename variable

Make the rewritten sql with the manifest name planned_sql.
Make the transpired sql by sqlglot name dialect_sql.

Minor

  • Fix config not stand-alone
  • Simply use raise_for_status
  • Add UnprocessableEntityError

@grieve54706 grieve54706 requested a review from goldmedal July 24, 2024 11:03
Copy link
Contributor

@goldmedal goldmedal left a comment

Choose a reason for hiding this comment

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

Thanks @grieve54706 there're some conflicts here.

@@ -42,7 +42,6 @@ To run the tests:

### Environment Variables
- `WREN_ENGINE_ENDPOINT`: The endpoint of the Wren Java engine
- `LOG_LEVEL`: The log level of the server (default is INFO)
Copy link
Contributor

Choose a reason for hiding this comment

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

Curiously, it seems that loguru doesn't use this env. How can we change the log level after moving to loguru?

Copy link
Contributor Author

@grieve54706 grieve54706 Jul 25, 2024

Choose a reason for hiding this comment

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

The main principle of loguru is that there are no levels. By default, everything is printed to sys.stderr. It then allows you to choose to output specific levels to designated files. Please refer to Delgan/loguru#138 (comment).
BTW, the default level is DEBUG.

Copy link
Contributor

Choose a reason for hiding this comment

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

So, everything is logged to sys.stderr. IMO, sys.stderr is not always printed in the console. Maybe we should check whether the environment in the docker container will print it or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After testing, the log will be printed in the console.

@grieve54706 grieve54706 force-pushed the feature/config-edit branch 2 times, most recently from 424e66e to 911b87b Compare July 25, 2024 03:25
return (
rewritten_sql
if self.data_source is None
else self.transpile(rewritten_sql)
)
except httpx.ConnectError as e:
raise ConnectionError(f"Can not connect to Wren Engine: {e}")
except httpx.HTTPStatusError as e:
raise RewriteError(e.response.text)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can also wrap the rewrite exception into RewriteError for EmbeddedEngineRewriter, then I guess we can be powered by the exception handler in v3/connector.py to generate the response.

Comment on lines 46 to 60
@app.patch("/config")
def update_config(diagnose: bool):
config = get_config()
config.update(diagnose=diagnose)
return config
Copy link
Contributor

Choose a reason for hiding this comment

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

How about adding a test to check if this update works?

@grieve54706 grieve54706 force-pushed the feature/config-edit branch from 911b87b to 541f248 Compare July 26, 2024 09:56
@grieve54706 grieve54706 requested a review from goldmedal July 26, 2024 09:56
Copy link
Contributor

@goldmedal goldmedal left a comment

Choose a reason for hiding this comment

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

Thanks @grieve54706 Looks nice to me. Just one question about config updating.

async def query_dry_run_error_handler(request, exc: QueryDryRunError):
return PlainTextResponse(str(exc), status_code=422)
@app.patch("/config")
def update_config(config_model: ConfigModel):
Copy link
Contributor

Choose a reason for hiding this comment

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

I saw you get_config().init_logger at L17. Should we init the logger again after updating the config?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We will remove the old logger and add a new logger when the config is updated in the config.py.

Comment on lines +25 to +27
def transpile(self, planned_sql: str) -> str:
dialect_sql = sqlglot.transpile(
planned_sql, read="trino", write=self.data_source.name
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@goldmedal goldmedal merged commit 04add7d into main Jul 26, 2024
4 checks passed
@grieve54706 grieve54706 deleted the feature/config-edit branch July 26, 2024 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants