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

[FEATURE] Exists function in DeltaTableStep should not log error #34

Open
menathan opened this issue May 30, 2024 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@menathan
Copy link

Is your feature request related to a problem? Please describe.

self.log.error(f"Table `{self.table}` doesn't exist.")

Exist function should not be biased when it comes to evaluating whether it is good or bad for a table to exist.

Describe the solution you'd like

Few possible suggestions:

  • change to warning or info
  • keep error, but check that if self.create_if_not_exists is false, then do log as an error.

Describe alternatives you've considered

N/A

Additional context

N/A

@menathan menathan added the enhancement New feature or request label May 30, 2024
@pariksheet
Copy link
Contributor

Assign it to Federica

dannymeijer added a commit that referenced this issue Oct 4, 2024
… run black

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->
The `exists` function of the `DeltaTableStep` should notify the user
about the non existence of the table with a different log level
depending on the value of the `create_if_not_exists` boolean flag
(whereas now it is logging always with level error).
If the flag is True than the log level is set to info. If the flag is
False than the log level is set to error.

A possible alternative is to set the log level always to info or warning
but this solution proposed already by the reporter looks more
informative.

## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an
issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps
to reproduce -->
<!--- Please link to the issue here: -->
#34 

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
Improving logging by making more informative and adeguate to the use
case.

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
By adding unit tests that verify the log message contains a certain
string.

## Screenshots (if appropriate):

## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [ ] All new and existing tests passed.

---------

Co-authored-by: Danny Meijer <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants