internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: dbt-labs/dbt-core

Issue:
[CT-2043] [Bug] Missing type (double) in `is_float` for databricks 
### Is this a new bug in dbt-core?

- [X] I believe this is a new bug in dbt-core
- [X] I have searched the existing issues, and I could not find an existing issue for this bug

### Current Behavior

I'm not sure if this belongs in here or the spark or the databricks adapator, but a `double` type column in databricks returns false for all of `is_float`, `is_numeric`, and `is_number`.

### Expected Behavior

It would return true for all those class method.

### Steps To Reproduce

1. Create a databricks table with a double column
2. Use `adapter.get_columns_in_relation(your_table)` and loop over the columns, logging or adding comments for the `.data_type` and the `.is_number()`
3. Observe the column with type `double` has `false` for `is_number()`

### Relevant log output

_No response_

### Environment

```markdown
- OS:
- Python:
- dbt: 1.4.1
```


### Which database adapter are you using with dbt?

other (mention it in "Additional Context")

### Additional Context

Using databricks as unable to test on spark, it is a delta table if that is relevant.

I believe it just needs to be added to the list here:
https://github.com/dbt-labs/dbt-core/blob/b2ea2b8b256e5db1da0b712dfedd7973e1e50a37/core/dbt/adapters/base/column.py#L55-L63


Discussion:
Thanks for opening @rlh1994!

While both `dbt-spark` and `dbt-databricks` implement their own `Column` class ([`SparkColumn`](https://github.com/dbt-labs/dbt-spark/blob/main/dbt/adapters/spark/column.py) and [`DatabricksColumn`](https://github.com/databricks/dbt-databricks/blob/main/dbt/adapters/databricks/column.py)), it doesn't look like either reimplements the `is_float` method. So, they're just using the `BaseAdapter.Column` method, defined in `dbt-core`, which you linked above.

Given that we already have `double precision` in the list above, and other data platforms (e.g. [Snowflake](https://docs.snowflake.com/en/sql-reference/data-types-numeric.html#double-double-precision-real)) also treat `DOUBLE` and `DOUBLE PRECISION` as true aliases, it seems reasonable to me that we'd add `double` to the default `is_float` method.

Is that a change you'd be up for making?
@jtcohen6 Sure I'll get a PR in for later, I can't immediately find any tests for this method anyway but we can discuss that in the PR.

Resolving patch:
diff --git a/core/dbt/adapters/base/column.py b/core/dbt/adapters/base/column.py
--- a/core/dbt/adapters/base/column.py
+++ b/core/dbt/adapters/base/column.py
@@ -60,6 +60,7 @@ def is_float(self):
             "float",
             "double precision",
             "float8",
+            "double",
         ]
 
     def is_integer(self) -> bool:


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2074] [Bug] Error message for exposures gives incorrect node type for TargetNotFound
### Is this a new bug in dbt-core?

- [X] I believe this is a new bug in dbt-core
- [X] I have searched the existing issues, and I could not find an existing issue for this bug

### Current Behavior

Assume I have the following exposure:

```yml
version: 2

exposures:

  - name: weekly_metrics
    label: Some Label
    type: dashboard
    maturity: high
    url: https://bi.tool/dashboards/1
    description: >
      Did someone say "exponential growth"?

    depends_on:
      - ref('fact_orders')
      - ref('dim_customers')
      - metric('testing')

    owner:
      name: Callum McData
      email: data@jaffleshop.com
```

But I the node `metric('testing')` does not actually exist in my project. If this is the case, I get the following error message when trying to compile:

> Compilation Error
  Exposure 'exposure.dbt_metrics_integration_tests.weekly_metrics' (models/materialized_models/exposures.yml) depends on a source named 'testing' which was not found

This is incorrect because we can clearly see that this is a `metric` and not a source. When trying out the same functionality with a model node, I get the correct type displayed in the error message. IE:
> depends on a node 'testing' which was not found



### Expected Behavior

I would expect that the CompilationError returned by dbt core would identify the correct target node type. However, for the life of me I cannot figure out where this is coming from. I am fairly certain the error message is arising from `TargetNotFoundError` but I was unable to find the path that routed into there with this issue.

### Steps To Reproduce

1. Create an exposure that is referencing a metric that doesn't exist

### Relevant log output

```shell
Shown in earlier messages
```


### Environment

```markdown
- OS: MacOS
- Python: 3.10
- dbt: 1.4.1
```


### Which database adapter are you using with dbt?

postgres

### Additional Context

_No response_


Discussion:
@callum-mcdata Thanks for opening! I think this is a one-liner:
https://github.com/dbt-labs/dbt-core/blob/311a57a21e61955904202bdb469c2077202e9073/core/dbt/parser/manifest.py#L1260-L1271

`target_kind` should be `"metric"`, not `"source"`!

Resolving patch:
diff --git a/core/dbt/parser/manifest.py b/core/dbt/parser/manifest.py
--- a/core/dbt/parser/manifest.py
+++ b/core/dbt/parser/manifest.py
@@ -1264,7 +1264,7 @@ def _process_metrics_for_node(
             invalid_target_fail_unless_test(
                 node=node,
                 target_name=target_metric_name,
-                target_kind="source",
+                target_kind="metric",
                 target_package=target_metric_package,
                 disabled=(isinstance(target_metric, Disabled)),
             )


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2079] [Regression] Logging Fix Accidentally Reverted in Feature Branch Merge
We recently addressed an issue (#6901 ) with missing flush() after write() to log streams. However, the feature branch merge (#6931) accidentally reverted that fix. We need to re-apply it to main.




Discussion:

Resolving patch:
diff --git a/core/dbt/events/eventmgr.py b/core/dbt/events/eventmgr.py
--- a/core/dbt/events/eventmgr.py
+++ b/core/dbt/events/eventmgr.py
@@ -88,41 +88,40 @@ def __init__(self, event_manager: "EventManager", config: LoggerConfig) -> None:
         self.level: EventLevel = config.level
         self.event_manager: EventManager = event_manager
         self._python_logger: Optional[logging.Logger] = config.logger
-        self._stream: Optional[TextIO] = config.output_stream
+
+        if config.output_stream is not None:
+            stream_handler = logging.StreamHandler(config.output_stream)
+            self._python_logger = self._get_python_log_for_handler(stream_handler)
 
         if config.output_file_name:
-            log = logging.getLogger(config.name)
-            log.setLevel(_log_level_map[config.level])
-            handler = RotatingFileHandler(
+            file_handler = RotatingFileHandler(
                 filename=str(config.output_file_name),
                 encoding="utf8",
                 maxBytes=10 * 1024 * 1024,  # 10 mb
                 backupCount=5,
             )
+            self._python_logger = self._get_python_log_for_handler(file_handler)
 
-            handler.setFormatter(logging.Formatter(fmt="%(message)s"))
-            log.handlers.clear()
-            log.addHandler(handler)
-
-            self._python_logger = log
+    def _get_python_log_for_handler(self, handler: logging.Handler):
+        log = logging.getLogger(self.name)
+        log.setLevel(_log_level_map[self.level])
+        handler.setFormatter(logging.Formatter(fmt="%(message)s"))
+        log.handlers.clear()
+        log.addHandler(handler)
+        return log
 
     def create_line(self, msg: EventMsg) -> str:
         raise NotImplementedError()
 
     def write_line(self, msg: EventMsg):
         line = self.create_line(msg)
-        python_level = _log_level_map[EventLevel(msg.info.level)]
         if self._python_logger is not None:
             send_to_logger(self._python_logger, msg.info.level, line)
-        elif self._stream is not None and _log_level_map[self.level] <= python_level:
-            self._stream.write(line + "\n")
 
     def flush(self):
         if self._python_logger is not None:
             for handler in self._python_logger.handlers:
                 handler.flush()
-        elif self._stream is not None:
-            self._stream.flush()
 
 
 class _TextLogger(_Logger):


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-1761] Update code comment for `build_manifest_state_check`
I believe this comment is no longer true! We should take credit for some of the good work we've done on partial parsing since April 2021 (https://github.com/dbt-labs/dbt-core/pull/3219).

https://github.com/dbt-labs/dbt-core/blob/d43c070007b823588e7a170c6c37495ce319b011/core/dbt/parser/manifest.py#L688-L694

Namely:
- we've handled changes in env vars since v1.0
- we do hash + compare the actual profile used
- re: `--vars`, if we did https://github.com/dbt-labs/dbt-core/issues/6323, we could rewrite that comment to be _even_ better :)


Discussion:

Resolving patch:
diff --git a/core/dbt/parser/manifest.py b/core/dbt/parser/manifest.py
--- a/core/dbt/parser/manifest.py
+++ b/core/dbt/parser/manifest.py
@@ -705,12 +705,8 @@ def build_perf_info(self):
             mli._project_index[project.project_name] = project_info
         return mli
 
-    # TODO: this should be calculated per-file based on the vars() calls made in
-    # parsing, so changing one var doesn't invalidate everything. also there should
-    # be something like that for env_var - currently changing env_vars in way that
-    # impact graph selection or configs will result in weird test failures.
-    # finally, we should hash the actual profile used, not just root project +
-    # profiles.yml + relevant args. While sufficient, it is definitely overkill.
+    # TODO: handle --vars in the same way we handle env_var
+    # https://github.com/dbt-labs/dbt-core/issues/6323
     def build_manifest_state_check(self):
         config = self.root_project
         all_projects = self.all_projects


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2129] [Bug] dbt --version hangs when access to PyPi is not available
### Is this a new bug in dbt-core?

- [X] I believe this is a new bug in dbt-core
- [X] I have searched the existing issues, and I could not find an existing issue for this bug

### Current Behavior

When using dbt --version a check is done at PypI.org if a newer version is available.
In many compagnies access to the internet is restricted. In that case dbt --version does wait forever and never exits.


### Expected Behavior

Make check at PyPi optional, or at least, timeout this check after some time in a proper way.

### Steps To Reproduce

dbt --version without access to PyPi.org

### Relevant log output

_No response_

### Environment

```markdown
- OS: any
- Python: any
- dbt: any
```


### Which database adapter are you using with dbt?

_No response_

### Additional Context

_No response_


Discussion:
Thanks for opening @flyingTiemen!

Paraphrasing from a slack convo I had with @aranke @stu-k a few weeks ago:

- **Better:** We should add an aggressive timeout to the "latest" check / PyPI API call
- **Best:** We print dbt version info _immediately_, turn the PyPI check into an async/background process, and only return the "latest" info if/when it's ready
- **Maybe:** Give users the option of disabling the "latest" check / PyPI API call entirely. This might be especially relevant in cases where folks want to run `--version` programmatically. (There are other things we'd need to do to enable like, above all returning version info as a JSON blob instead of colorful pretty-printed text.)

I think the quickest quality-of-life improvement here would be adding an aggressive timeout (e.g. 1s) to this line:
https://github.com/dbt-labs/dbt-core/blob/b7884facbff0180e0f37516ed6896efc837cc953/core/dbt/version.py#L45
```python
 resp = requests.get(version_url, timeout=1)
```

Would you be interested in contributing that quick change?
Tested the quick change, that works fine.

I'm new to contributing to a project on GitHub, I'm not sure if I can add. I'm also behind a firewall which makes access to GiHub a bit problematic (for cloning and commits etc).
Potentially a dupe of https://github.com/dbt-labs/dbt-core/issues/6085
I'm going to mark this as a `good_first_issue`, at least for the simplest "better" solution: add a retry timeout of 1 second :)

@aranke Should we keep #6085 open, and more narrowly scoped to the "best" solution proposed above — yielding information as it becomes available? (I think that's what your approach in #6083 was after)
Yup, sounds good @jtcohen6!

Resolving patch:
diff --git a/core/dbt/version.py b/core/dbt/version.py
--- a/core/dbt/version.py
+++ b/core/dbt/version.py
@@ -42,7 +42,7 @@ def get_latest_version(
     version_url: str = PYPI_VERSION_URL,
 ) -> Optional[dbt.semver.VersionSpecifier]:
     try:
-        resp = requests.get(version_url)
+        resp = requests.get(version_url, timeout=1)
         data = resp.json()
         version_string = data["info"]["version"]
     except (json.JSONDecodeError, KeyError, requests.RequestException):


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2160] [Regression] "Legacy" Logging Broken in 1.4.2rc1
### Is this a regression in a recent version of dbt-core?

- [X] I believe this is a regression in dbt-core functionality
- [X] I have searched the existing issues, and I could not find an existing issue for this regression

### Current Behavior

When running a dbt command from the cli with the DBT_USE_LEGACY_LOGGER env var set, the console logs are written via a standard Python logger, rather than the logbook logger, as they should be to support legacy logging scenarios correctly.

### Expected/Previous Behavior

Logging should be directed to the logbook log with this flags set, just as it was in 1.4.1.

### Steps To Reproduce

Issue was seen when running `dbt build` with DBT_USE_LEGACY_LOGGER=True on the jaffle_shop project with 1.4.2rc1 on macOS with Python 3.10, but likely affects all platforms, Python versions, and projects.

### Relevant log output

At the console, logs look the same, but integrations relying on logbook are failing.

### Environment

```markdown
- OS: macOS
- Python: 3.10
- dbt (working version): 1.4.1
- dbt (regression version): 1.4.2rc1
```


### Which database adapter are you using with dbt?

postgres

### Additional Context

_No response_


Discussion:

Resolving patch:
diff --git a/core/dbt/events/functions.py b/core/dbt/events/functions.py
--- a/core/dbt/events/functions.py
+++ b/core/dbt/events/functions.py
@@ -102,6 +102,7 @@ def _get_logbook_log_config(level: Optional[EventLevel] = None) -> LoggerConfig:
     config.name = "logbook_log"
     config.filter = NoFilter if flags.LOG_CACHE_EVENTS else lambda e: not isinstance(e.data, Cache)
     config.logger = GLOBAL_LOGGER
+    config.output_stream = None
     return config
 
 


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-1943] Loosen pin on `jsonschema` (via `hologram`)
For more context on our latest thinking around dependencies (how & why we pin today, and how we want it to change):
- https://github.com/dbt-labs/dbt-core/discussions/6495

### Summary

`dbt-core` depends on `hologram`, and as such it also includes `hologram`'s transitive dependencies on `jsonschema` and `python-dateutil`. `hologram`'s upper bound on `jsonschema` in particular is causing issues for some folks trying to install `dbt-core` alongside other popular tools, such as Airflow:
- https://github.com/dbt-labs/hologram/issues/52
- https://github.com/dbt-labs/hologram/pull/51

### Short term

- Try removing upper bound on `jsonschema`
- Release a new version of `hologram` with no / looser upper bound
- Support the new version of `hologram` [in `dbt-core`](https://github.com/dbt-labs/dbt-core/blob/a8abc496323f741d3218d298d5d2bb118fa01017/core/setup.py#L54)

### Medium term

Remove `dbt-core`'s dependency on `hologram` entirely. It doesn't do nearly as much for us today as it used to, and the validation errors it raises aren't even all that nice.
- https://github.com/dbt-labs/dbt-core/issues/6776


Discussion:
Part of this will be determining how to release hologram since we have not done that recently.
Is this targeted for being included with the 1.5 release?
@r-richmond This hasn't been a top priority for us, compared to other planned work for v1.5, but I understand it's a pain for a number of folks who need to install `dbt-core` alongside other Python programs that require newer versions of `jsonschema`.

I just opened a quick PR to run CI with the latest version of `jsonschema`: https://github.com/dbt-labs/dbt-core/pull/7219. If this "just works," we can try to sneak it in for v1.5.

> Part of this will be determining how to release hologram since we have not done that recently.

@emmyoop I think it's just a manual release to PyPI.
I've released hologram 0.0.16

Resolving patch:
diff --git a/core/setup.py b/core/setup.py
--- a/core/setup.py
+++ b/core/setup.py
@@ -50,7 +50,7 @@
         "agate>=1.6,<1.7.1",
         "click>=7.0,<9",
         "colorama>=0.3.9,<0.4.7",
-        "hologram>=0.0.14,<=0.0.15",
+        "hologram>=0.0.14,<=0.0.16",
         "isodate>=0.6,<0.7",
         "logbook>=1.5,<1.6",
         "mashumaro[msgpack]==3.3.1",


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2375] [Bug] dbtRunner instances share the callbacks across instances when no callbacks are passed
### Is this a new bug in dbt-core?

- [X] I believe this is a new bug in dbt-core
- [X] I have searched the existing issues, and I could not find an existing issue for this bug

### Current Behavior

```py
from dbt.cli.main import dbtRunner, list
from dbt.events.base_types import EventMsg

def print_callback(event: EventMsg):
    print("Got an event:", event.info.name)

dbt = dbtRunner()
dbt.callbacks.append(print_callback)

dbt2 = dbtRunner()
dbt2.invoke(['list'])   # this prints the event names
```

example run:

```
❯ python runner.py
16:32:42  Running with dbt=1.5.0-b5
Got an event: MainReportVersion
Got an event: MainReportArgs
16:32:42  [WARNING]: Deprecated functionality
The `target-path` config in `dbt_project.yml` has been deprecated, and will no
longer be supported in a future version of dbt-core. If you wish to write dbt
artifacts to a custom directory, please use the --target-path CLI flag or
DBT_TARGET_PATH env var instead.
Got an event: ConfigTargetPathDeprecation
Got an event: SendingEvent
Got an event: SendingEvent
Got an event: SendingEvent
Got an event: StateCheckVarsHash
Got an event: PartialParsingEnabled
Got an event: PartialParsingSkipParsing
Got an event: SendingEvent
Got an event: SendingEvent
16:32:42  Found 4 models, 0 tests, 0 snapshots, 0 analyses, 309 macros, 0 operations, 0 seed files, 0 sources, 0 exposures, 0 metrics, 0 groups
Got an event: FoundStats
Got an event: SendingEvent
simple_test.base.model_a
simple_test.base.model_b
simple_test.python.model_c
simple_test.model_d
Got an event: CommandCompleted
Got an event: SendingEvent
Got an event: FlushEvents
```

### Expected Behavior

dbtRunner instances should be isolated from one another.

### Steps To Reproduce

See current behavior

### Relevant log output

_No response_

### Environment

```markdown
- OS: macOS Ventura
- Python: Python 3.8.13
- dbt: 1.5.0-b5
```


### Which database adapter are you using with dbt?

postgres

### Additional Context

https://stackoverflow.com/questions/366422/how-can-i-avoid-issues-caused-by-pythons-early-bound-default-parameters-e-g-m


Discussion:

Resolving patch:
diff --git a/core/dbt/cli/main.py b/core/dbt/cli/main.py
--- a/core/dbt/cli/main.py
+++ b/core/dbt/cli/main.py
@@ -40,11 +40,14 @@ def __init__(
         project: Project = None,
         profile: Profile = None,
         manifest: Manifest = None,
-        callbacks: List[Callable[[EventMsg], None]] = [],
+        callbacks: List[Callable[[EventMsg], None]] = None,
     ):
         self.project = project
         self.profile = profile
         self.manifest = manifest
+
+        if callbacks is None:
+            callbacks = []
         self.callbacks = callbacks
 
     def invoke(self, args: List[str]) -> Tuple[Optional[List], bool]:


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2382] [Feature] allow a broader list of mashumaro versions.
### Is this your first time submitting a feature request?

- [X] I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
- [X] I have searched the existing issues, and I could not find an existing issue for this feature
- [X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

### Describe the feature

Allow more mashumaro versions.

### Describe alternatives you've considered

patching the requirment (setup.py) locally.

### Who will this benefit?

any packager.

### Are you interested in contributing this feature?

Sure.

### Anything else?

I'm in the process of packaging dbt for AUR (arch), so the requirment on mashumaro has to be the current one (system-wide install and no virtual env).

BTW, I have the same issue with pathspec, and hologram at least. (and the test is running fine).


Discussion:

Resolving patch:
diff --git a/core/setup.py b/core/setup.py
--- a/core/setup.py
+++ b/core/setup.py
@@ -53,7 +53,7 @@
         "hologram>=0.0.14,<=0.0.16",
         "isodate>=0.6,<0.7",
         "logbook>=1.5,<1.6",
-        "mashumaro[msgpack]==3.3.1",
+        "mashumaro[msgpack]==3.6",
         "minimal-snowplow-tracker==0.0.2",
         "networkx>=2.3,<2.8.1;python_version<'3.8'",
         "networkx>=2.3,<3;python_version>='3.8'",


Test patch:
Repository: dbt-labs/dbt-core

Issue:
[CT-2417] Typo in statically parsed ref unpacking
There's a typo in line 495 of core/dbt/parser/models.py, when rearranging the model_name, package_name args, it uses refs[1] instead of ref[1]


Discussion:

Resolving patch:
diff --git a/core/dbt/parser/models.py b/core/dbt/parser/models.py
--- a/core/dbt/parser/models.py
+++ b/core/dbt/parser/models.py
@@ -492,7 +492,7 @@ def populate(self, node: ModelNode, config: ContextConfig, statically_parsed: Di
             if len(ref) == 1:
                 package, name = None, ref[0]
             else:
-                package, name = ref[0], refs[1]
+                package, name = ref
 
             refs.append(RefArgs(package=package, name=name))
 


Test patch:
diff --git a/test/unit/test_graph.py b/test/unit/test_graph.py
--- a/test/unit/test_graph.py
+++ b/test/unit/test_graph.py
@@ -215,6 +215,37 @@ def test__two_models_simple_ref(self):
             ],
         )
 
+    def test__two_models_package_ref(self):
+        self.use_models(
+            {
+                "model_one": "select * from events",
+                "model_two": "select * from {{ref('test_models_compile', 'model_one')}}",
+            }
+        )
+
+        config = self.get_config()
+        manifest = self.load_manifest(config)
+        compiler = self.get_compiler(config)
+        linker = compiler.compile(manifest)
+
+        self.assertCountEqual(
+            linker.nodes(),
+            [
+                "model.test_models_compile.model_one",
+                "model.test_models_compile.model_two",
+            ],
+        )
+
+        self.assertCountEqual(
+            linker.edges(),
+            [
+                (
+                    "model.test_models_compile.model_one",
+                    "model.test_models_compile.model_two",
+                )
+            ],
+        )
+
     def test__model_materializations(self):
         self.use_models(
             {