Repository: dbt-labs/dbt-core

Issue:
Reword or remove "Acquiring new ... connection" logline
### Describe the feature

This line of code confuses a lot of folks because it's logged to `logs/dbt.log`:

https://github.com/fishtown-analytics/dbt/blob/ec0f3d22e792127e9c2c709f369e1faf8eb13c8d/core/dbt/adapters/base/connections.py#L138-L139

As worded, it's pretty misleading! I'm also not convinced it's accurate: it's logged by commands that don't strictly need database connections (e.g. `dbt ls`, `dbt parse`). This is relevant to our thinking around formally separating project parsing from compilation/execution, as a step that requires minimal adapter-specific logic and does _not_ require a database (or Internet) connection.

### Why fix?

This leads folks to think that:
- dbt is opening dozens/hundreds of concurrent connections against their database
- The slowness of project parsing is due to opening and closing these connections

This has cropped up in https://github.com/fishtown-analytics/dbt/issues/2948, https://github.com/fishtown-analytics/dbt/issues/3135, and [several](https://getdbt.slack.com/archives/C50NEBJGG/p1613747946053600) [Slack](https://getdbt.slack.com/archives/C2JRRQDTL/p1607550107300400) [threads](https://getdbt.slack.com/archives/C2JRRQDTL/p1605635522217200), to name a few.

### History

As best as I can tell, the reason for having it seems to be that, during project parsing, we _may_ need an adapter connection, though I can't think of when/why we would:

https://github.com/fishtown-analytics/dbt/blob/344a14416d22f0cfbeb56b9904092c8a4f38b1fc/core/dbt/parser/base.py#L279-L289

Looking through older commits, it seems like we envisioned a future where this wouldn't be necessary. I'm not sure why it is necessary today.

https://github.com/fishtown-analytics/dbt/blob/b8febddad5f16e1cd02be8d8a00b3e8effb0e105/core/dbt/context/providers.py#L686-L699


Discussion:
This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.
I'd still like to fix this one. I think it could be a very quick quality-of-life improvement.

Resolving patch:
diff --git a/core/dbt/parser/base.py b/core/dbt/parser/base.py
--- a/core/dbt/parser/base.py
+++ b/core/dbt/parser/base.py
@@ -13,7 +13,7 @@
     generate_parser_model,
     generate_generate_component_name_macro,
 )
-from dbt.adapters.factory import get_adapter
+from dbt.adapters.factory import get_adapter  # noqa: F401
 from dbt.clients.jinja import get_rendered
 from dbt.config import Project, RuntimeConfig
 from dbt.context.context_config import (
@@ -260,17 +260,13 @@ def render_with_context(self, parsed_node: IntermediateNode, config: ContextConf
         # Given the parsed node and a ContextConfig to use during parsing,
         # render the node's sql wtih macro capture enabled.
         # Note: this mutates the config object when config calls are rendered.
+        context = self._context_for(parsed_node, config)
 
-        # during parsing, we don't have a connection, but we might need one, so
-        # we have to acquire it.
-        with get_adapter(self.root_project).connection_for(parsed_node):
-            context = self._context_for(parsed_node, config)
-
-            # this goes through the process of rendering, but just throws away
-            # the rendered result. The "macro capture" is the point?
-            get_rendered(
-                parsed_node.raw_sql, context, parsed_node, capture_macros=True
-            )
+        # this goes through the process of rendering, but just throws away
+        # the rendered result. The "macro capture" is the point?
+        get_rendered(
+            parsed_node.raw_sql, context, parsed_node, capture_macros=True
+        )
         return context
 
     # This is taking the original config for the node, converting it to a dict,


Test patch: