feat(ingest/snowflake): integrate snowflake-queries into main source

[hsheth2]

Follow up on #10835

• Integrate the SnowflakeQueriesExtractor into the main snowflake source.
• Allow for view lineage parsing without requiring query-based lineage/usage too.
• Add remaining missing configs (usage configs, lazy_graph)
• Add support for the known lineage mappings (e.g. snowflake external tables) to the snowflake-queries source.
• Add a tool extractor + initial extractor implementations.
• User -> urn mapping for email-based urns.
• Remove dead code from the include_view_lineage flag.

Other changes

• Refactors SnowflakeFilterMixin to use composition w/ SnowflakeFilter
• Similar with SnowflakeIdentifierBuilder
• Remove the SnowflakeCommonProtocol
• Simplify SnowflakeStructuredReportMixin
• Drastically reduce the number of methods in SnowflakeCommonMixin, using composition instead.
• Improves human-readability of error/warning reporting throughout the source.

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
• For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Summary by CodeRabbit

• New Features

  • Introduced new configuration options and fields to enhance Snowflake ingestion capabilities.

• Bug Fixes

  • Improved error handling and reporting mechanisms across multiple Snowflake ingestion methods.

• Refactor

  • Streamlined the Snowflake ingestion pipeline by renaming and restructuring methods and parameters for better clarity and performance.
  • Simplified test setup for Snowflake shares by removing redundant URN generation functions.

• Performance

  • Enhanced query extraction and processing for Snowflake data sources.

[coderabbitai]

Walkthrough

The changes enhance the Snowflake ingestion capabilities in DataHub. Key updates include adding new configuration options, restructuring the SnowflakeSchemaGenerator class, refining error handling, and improving query extraction methods. These modifications streamline schema resolution, enhance structured reporting, and simplify test configurations.

Changes

Files / Groups	Change Summary
snowflake_config.py	Added descriptions for convert_urns_to_lowercase, renamed and added fields for schema resolution.
snowflake_schema_gen.py	Updated class structure, method parameters, and error handling in SnowflakeSchemaGenerator.
snowflake_queries.py	Added imports, updated classes and methods for query extraction and filtering.
snowflake_v2.py	Introduced new classes, enhanced connection handling, and updated work unit generation.
test_snowflake_shares.py	Simplified SnowflakeSharesHandler instantiation in test cases.
sql_parsing_aggregator.py	Added parameters for schema resolution and updated schema necessity logic.

Amidst the code’s intricate dance,
Snowflake’s essence we enhance.
With queries deft and errors tamed,
Our ingestion beast is finely framed.
In the fields of data, we stand tall,
Celebrating changes, big and small!

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 10

Outside diff range, codebase verification and nitpick comments (5)

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_config.py (3)

134-134: Ensure consistency in documentation and naming conventions.

The description for convert_urns_to_lowercase is somewhat unclear. It could be improved to better explain the implications of this setting on the integration with other sources.

-        description="Whether to convert dataset urns to lowercase.",
+        description="Determines whether dataset URNs should be converted to lowercase to ensure consistency across different sources.",

---

134-134: Validation logic for include_view_lineage needs clarification.

The validator for include_view_lineage throws a ValueError if include_table_lineage is not true while include_view_lineage is set. This dependency should be clearly documented in the description of include_view_lineage.

-        description="If enabled, populates the snowflake view->table and table->view lineages. Requires appropriate grants given to the role, and include_table_lineage to be True. view->table lineage requires Snowflake Enterprise Edition or above.",
+        description="If enabled, populates the snowflake view->table and table->view lineages. Requires `include_table_lineage` to be True and appropriate grants given to the role. View->table lineage requires Snowflake Enterprise Edition or above.",

---

209-215: Clarify the use of new configuration fields related to query extraction.

The introduction of use_queries_v2 and lazy_schema_resolver adds complexity. Ensure that the purpose and use cases of these fields are well-documented to avoid confusion.

+        description="If enabled, uses the new queries extractor to extract queries from snowflake. This is part of an experimental feature set aimed at improving performance and accuracy of schema resolution.",
+        description="If enabled, uses lazy schema resolution to resolve schemas for tables and views. This method delays schema fetching until absolutely necessary, which can improve performance in environments with a large number of schemas.",

metadata-ingestion/src/datahub/ingestion/api/source.py (1)

294-311: Introduced report_exc method for improved error handling with context management.

The new report_exc context manager method simplifies error handling by encapsulating the try-except logic, making the code cleaner and more maintainable. However, the comment on line 304 suggests dissatisfaction with the method's naming due to its non-obvious behavior.

Suggestion: Consider renaming or improving documentation.

Clarifying the method's behavior in its name or documentation could improve code readability and prevent misuse.

- # TODO: I'm not super happy with the naming here - it's not obvious that this
- # suppresses the exception in addition to reporting it.
+ # TODO: Consider renaming `report_exc` to `suppress_and_report_exc` to clarify that it suppresses and reports exceptions.

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_queries.py (1)

Line range hint 116-423: Enhanced Snowflake query extraction logic.

The refactoring and enhancements in the Snowflake query extraction logic, including better error handling and structured reporting, improve the robustness and maintainability of the code. The use of modern Python features like dataclasses and structured error reporting aligns with best practices.

However, there are several TODO comments indicating areas for future improvement, such as stateful ingestion and handling of external tables.

Suggestion: Address TODO items in future iterations.

It would be beneficial to plan for addressing these TODO items in upcoming development cycles to ensure the completeness and scalability of the Snowflake ingestion functionality.

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 643ba0c and 1578f31.

Files selected for processing (20)

• metadata-ingestion/src/datahub/ingestion/api/source.py (8 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_assertion.py (5 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_config.py (2 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_lineage_v2.py (13 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_profiler.py (2 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_queries.py (15 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_report.py (2 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_schema.py (2 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_schema_gen.py (28 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_shares.py (5 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_summary.py (4 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_tag.py (3 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_usage_v2.py (11 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_utils.py (7 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_v2.py (9 hunks)
• metadata-ingestion/src/datahub/ingestion/source/sql/athena.py (1 hunks)
• metadata-ingestion/src/datahub/ingestion/source/sql/sql_config.py (1 hunks)
• metadata-ingestion/src/datahub/ingestion/source_report/ingestion_stage.py (1 hunks)
• metadata-ingestion/src/datahub/sql_parsing/sql_parsing_aggregator.py (5 hunks)
• metadata-ingestion/tests/unit/test_snowflake_shares.py (5 hunks)

Files skipped from review due to trivial changes (3)

• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_schema.py
• metadata-ingestion/src/datahub/ingestion/source_report/ingestion_stage.py
• metadata-ingestion/tests/unit/test_snowflake_shares.py

Additional context used

Ruff

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_utils.py

162-170: Return the negated condition directly

Inline condition

(SIM103)

Additional comments not posted (30)

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_assertion.py (5)

48-48: Refactor to use identifiers parameter in SnowflakeAssertionsHandler.

The introduction of the identifiers parameter in the constructor is a good use of composition over inheritance, aligning with the PR's objectives to simplify and refactor existing code.

---

53-53: Proper initialization of identifiers.

The identifiers attribute is properly initialized and stored for later use, which is consistent with the changes made in the constructor.

---

79-82: Dynamic platform instance URN generation.

This change dynamically generates the platform instance URN based on the configuration, which adds flexibility to handle different instances. This is a significant improvement in handling multi-instance scenarios.

---

97-97: Use of identifiers for dataset identification.

The method get_dataset_identifier from identifiers is used here to dynamically generate dataset identifiers, which is a cleaner and more modular approach than hardcoding or duplicating logic.

---

106-106: Dynamic generation of dataset URN.

The use of gen_dataset_urn from identifiers to dynamically generate dataset URNs is a good practice, ensuring consistency and reusability of URN generation logic across the codebase.

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_summary.py (1)

76-79: Introduction of SnowflakeIdentifierBuilder in SnowflakeSchemaGenerator.

The use of SnowflakeIdentifierBuilder to handle identifier generation is a positive change. It centralizes the logic for creating identifiers, which can help maintain consistency and reduce errors in identifier creation.

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_tag.py (1)

71-71: Use of identifiers for generating quoted identifiers.

The changes effectively utilize the identifiers object to generate quoted identifiers for databases, schemas, and tables. This ensures consistency and correctness in handling identifiers, which is crucial for accurate tag extraction.

Also applies to: 74-76, 82-82, 144-144

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_shares.py (2)

94-97: Improved error reporting for missing databases in shares configuration.

The addition of a structured warning message when databases referenced by the share configurations are not ingested is a good practice. It improves transparency and aids in troubleshooting.

---

114-114: Consistent use of identifiers for URN generation.

The consistent use of identifiers to generate dataset identifiers and URNs across different methods enhances modularity and reusability. This approach simplifies the maintenance and scalability of the code.

Also applies to: 117-117, 121-122, 142-142, 145-145, 148-149

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_report.py (2)

18-20: Addition of SnowflakeQueriesExtractorReport import.

The import of SnowflakeQueriesExtractorReport is crucial for the new functionality introduced in this PR. It's good to see that the new types are being integrated properly.

---

119-120: Addition of queries_extractor field in SnowflakeV2Report.

The new queries_extractor field in SnowflakeV2Report is optional and seems to be aligned with the PR's objective to enhance the Snowflake source with new extractor capabilities. This change supports the integration of SnowflakeQueriesExtractor into the main source, which is a key objective of the PR.

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_profiler.py (1)

88-88: New method for generating dataset names.

The addition of get_dataset_name method in SnowflakeProfiler is a significant enhancement. It abstracts the dataset naming logic into a single method, which improves modularity and maintainability. This change is well-aligned with the principles of clean code.

metadata-ingestion/src/datahub/ingestion/source/sql/sql_config.py (1)

86-86: Making include_views and include_tables required boolean fields.

The explicit requirement for include_views and include_tables to be boolean is a good practice, ensuring that the configuration is robust and less prone to errors. This change also clarifies the expected input types for these fields, enhancing the configuration's usability and maintainability.

Also applies to: 89-89

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_utils.py (1)

106-111: Introduction of SnowflakeFilter class.

The new SnowflakeFilter class encapsulates filtering logic, which is a positive step towards improving the modularity and maintainability of the code. This class uses the SnowflakeFilterConfig and SourceReport for its operations, which integrates well with the existing architecture.

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_lineage_v2.py (1)

431-445: Optimize Dataset Identifier Lookup

The method map_query_result_upstreams repeatedly calls self.identifiers.get_dataset_identifier_from_qualified_name inside a loop. Consider optimizing this by caching results or restructuring the code to reduce the frequency of these calls, especially if they are computationally expensive or involve network calls.

[performance]

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_schema_gen.py (9)

145-154: Refactor of Constructor Parameters and Composition

The refactoring to use composition over inheritance by introducing filters and identifiers directly in the constructor is a positive change. It enhances modularity and makes dependencies more explicit.

Also applies to: 163-164

---

192-196: Simplification of Identifier Methods

The methods gen_dataset_urn and snowflake_identifier are now simplified and directly use the identifiers object. This change improves readability and maintainability by reducing the complexity within the class.

---

216-219: Enhanced Error Handling with Structured Reporting

The use of structured_reporter.failure to handle exceptions related to permissions and database listing is a robust enhancement. It ensures that errors are not only logged but also categorized correctly, which can be crucial for debugging and monitoring.

Also applies to: 228-230, 239-239

---

Line range hint 282-292: Improved Warning Messages for Permission Issues

The addition of detailed warning messages when encountering permission issues during database operations is a good practice. It aids in troubleshooting by providing clear guidance on what might be wrong.

---

443-448: View Definition Parsing Enhancement

The integration of view definition parsing in the method _process_schema is a significant enhancement. It allows for better lineage tracking and understanding of view dependencies. The use of aggregator.add_view_definition is appropriate and aligns with the objectives of enhancing view lineage parsing.

---

463-466: Warning for Missing Tables/Views

The method _process_schema now includes a warning for schemas that do not contain tables or views. This is a helpful diagnostic tool for users to understand potential configuration or permission issues.

---

525-528: Error Handling in Table Fetching

The method fetch_tables_for_schema follows a consistent pattern in error handling as seen in other parts of the class. The structured reporting of errors helps in quick identification and resolution of issues related to permissions.

---

561-562: Consistent Warning Reporting for Table and Column Fetching

The methods _process_table, fetch_foreign_keys_for_table, and fetch_pk_for_table use structured reporting to warn about issues in fetching table details. This consistency in error handling across the class helps maintain a uniform approach to error reporting.

Also applies to: 596-597, 612-613

---

636-637: Warning for Missing Columns in Views

The method _process_view includes a warning for missing columns in views, which is crucial for ensuring data completeness and integrity. This aligns with the overall strategy of robust error handling in the class.

metadata-ingestion/src/datahub/sql_parsing/sql_parsing_aggregator.py (2)

Line range hint 254-322: Refactor: Schema Resolver Initialization

The refactoring of the schema resolver initialization in the SqlParsingAggregator constructor is well-structured. The use of conditions to determine whether to use an explicitly provided resolver or to initialize one based on the graph client is clear and maintains separation of concerns.

However, ensure that the conditions for initializing the schema resolver are thoroughly tested, especially the transitions between using an explicitly provided resolver and the lazy-loading mechanism.

---

411-417: Check the Necessity of Schema Information

The method _need_schemas is a concise way to determine if schema information is necessary based on the features enabled. This method enhances readability and maintainability by centralizing the check.

Ensure that all features that require schema information are accounted for in this method to prevent runtime errors due to missing schema data.

metadata-ingestion/src/datahub/ingestion/api/source.py (2)

1-1: Added imports for context management and iteration.

The addition of contextlib and Iterator imports are appropriate for the new functionalities introduced in this file, specifically for the report_exc method which uses a context manager.

Also applies to: 14-14

---

Line range hint 102-116: Enhanced logging and error handling in structured logging.

The introduction of the stacklevel parameter and the adjustments in stack level calculations improve the accuracy of the source location in logs, which is beneficial for debugging. The use of structured logging is consistent with modern Python practices and enhances the readability and maintainability of log management.

Also applies to: 264-279, 288-291

metadata-ingestion/src/datahub/ingestion/source/sql/athena.py (1)

Line range hint 1-1: Removed unused field _s3_staging_dir.

The removal of the _s3_staging_dir field and its replacement with query_result_location aligns with the changes mentioned in the PR summary, focusing on simplification and modernization of configuration handling.

metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_queries.py (1)

Line range hint 66-97: Refactored configuration handling in Snowflake queries.

The integration of SnowflakeQueriesExtractorConfig with SnowflakeIdentifierConfig and SnowflakeFilterConfig into SnowflakeQueriesSourceConfig simplifies the configuration management by using inheritance, which is a good practice in object-oriented programming.

[coderabbitai]

Error Handling in View Fetching

The method fetch_views_for_schema uses structured reporting for error handling, which is consistent with other parts of the code. However, the exception handling could be more specific to different types of errors, similar to the suggestion for fetch_schemas_for_database.

-        except Exception as e:
+        except SnowflakePermissionError as spe:
+            self.structured_reporter.warning(
+                "Permission issues encountered while fetching views",
+                f"{db_name}.{schema_name}",
+                exc=spe,
+            )
+        except Exception as e:

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	self.structured_reporter.warning(
	"Failed to get views for schema",
	f"{db_name}.{schema_name}",
	exc=e,
	self.structured_reporter.warning(
	"Failed to get views for schema",
	f"{db_name}.{schema_name}",
	exc=e,
	)
	except SnowflakePermissionError as spe:
	self.structured_reporter.warning(
	"Permission issues encountered while fetching views",
	f"{db_name}.{schema_name}",
	exc=spe,
	)
	except Exception as e:

[coderabbitai]

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 1578f31 and abfc574.

Files selected for processing (2)

• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_config.py (2 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_schema_gen.py (28 hunks)

Files skipped from review as they are similar to previous changes (2)

• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_config.py
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_schema_gen.py

[coderabbitai]

Actionable comments posted: 1

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between abfc574 and dcb786f.

Files selected for processing (3)

• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_queries.py (16 hunks)
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_v2.py (9 hunks)
• metadata-ingestion/src/datahub/sql_parsing/sql_parsing_aggregator.py (6 hunks)

Files skipped from review as they are similar to previous changes (2)

• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_queries.py
• metadata-ingestion/src/datahub/ingestion/source/snowflake/snowflake_v2.py

Additional comments not posted (4)

metadata-ingestion/src/datahub/sql_parsing/sql_parsing_aggregator.py (4)

254-256: Refactor: Introduce schema_resolver and eager_graph_load parameters in __init__ method.

The addition of schema_resolver and eager_graph_load parameters allows for flexible schema resolution strategies. This is a positive change as it supports both eager and lazy loading of schemas based on the configuration, which can improve performance depending on the use case.

---

306-326: Enhancement: Schema Resolver Initialization Logic

The logic for initializing the schema_resolver is well-structured, supporting both explicit provision and lazy loading via the graph client. This flexibility is crucial for adapting to different deployment environments and configurations.

---

394-395: Duplicate Comment: Configuration Misuse

The previous comment about the misuse of BaseUsageConfig is still relevant. The use of a broad configuration class in a context where many properties are not applicable can lead to confusion and potential bugs.

---

415-421: Refactor: Simplify _need_schemas Property Logic

The updated logic in _need_schemas property now covers more scenarios where schema information might be necessary, enhancing the robustness of schema handling in different operational contexts.

[coderabbitai]

Logic Issue: Potential Misleading Warning Message

The warning message about queries not being generated could be misleading because it is logged even when generate_queries is true but both generate_lineage and generate_query_usage_statistics are false. This could lead to confusion about the actual behavior of the system.

- if self.generate_queries and not (
-     self.generate_lineage or self.generate_query_usage_statistics
- ):
-     logger.warning(
-         "Queries will not be generated, as neither lineage nor query usage statistics are enabled"
-     )
+ if not self.generate_lineage and not self.generate_query_usage_statistics:
+     if self.generate_queries:
+         logger.warning(
+             "Queries will not be generated, as neither lineage nor query usage statistics are enabled"
+         )
+     else:
+         logger.debug(
+             "Neither lineage nor query usage statistics nor query generation are enabled"
+         )

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if self.generate_queries and not (
	self.generate_lineage or self.generate_query_usage_statistics
	):
	logger.warning(
	"Queries will not be generated, as neither lineage nor query usage statistics are enabled"
	)
	if not self.generate_lineage and not self.generate_query_usage_statistics:
	if self.generate_queries:
	logger.warning(
	"Queries will not be generated, as neither lineage nor query usage statistics are enabled"
	)
	else:
	logger.debug(
	"Neither lineage nor query usage statistics nor query generation are enabled"
	)