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

Issue:
When using the `package` syntax without `version`, dbt returns a vague error message

## Issue

### Issue description
When using the `package` syntax without `version`, dbt returns a vague error message:
```
$ cat packages.yml
packages:
  - package: fishtown-analytics/dbt_utils
$ dbt deps
Running with dbt=0.14.0-a1
Encountered an error:
'version'
```
### Expected result
An error message more like:
```
No version was specified for package "fishtown-analytics/dbt_utils"
```
(Even that's not super helpful tbh)



Discussion:

Resolving patch:
diff --git a/core/dbt/contracts/project.py b/core/dbt/contracts/project.py
--- a/core/dbt/contracts/project.py
+++ b/core/dbt/contracts/project.py
@@ -243,7 +243,7 @@ class Project(APIObject):
             'description': 'The version of the package',
         },
     },
-    'required': ['package'],
+    'required': ['package', 'version'],
 }
 
 
diff --git a/core/dbt/task/deps.py b/core/dbt/task/deps.py
--- a/core/dbt/task/deps.py
+++ b/core/dbt/task/deps.py
@@ -118,6 +118,11 @@ class RegistryPackage(Package):
     SCHEMA = REGISTRY_PACKAGE_CONTRACT
 
     def __init__(self, *args, **kwargs):
+        if 'version' not in kwargs:
+            dbt.exceptions.raise_dependency_error(
+                'package dependency {} is missing a "version" field'
+                .format(kwargs.get('package'))
+            )
         super(RegistryPackage, self).__init__(*args, **kwargs)
         self._version = self._sanitize_version(self._contents['version'])
 


Test patch:
diff --git a/test/unit/test_deps.py b/test/unit/test_deps.py
--- a/test/unit/test_deps.py
+++ b/test/unit/test_deps.py
@@ -73,7 +73,7 @@ def test_init(self):
         self.assertEqual(a.source_type(), 'hub')
 
     def test_invalid(self):
-        with self.assertRaises(dbt.exceptions.ValidationException):
+        with self.assertRaises(dbt.exceptions.DependencyException):
             RegistryPackage(package='namespace/name', key='invalid')
 
     def test_resolve_ok(self):
Repository: dbt-labs/dbt-core

Issue:
Add materializations dirs to include paths for pg/redshift
## Issue

### Issue description
The 0.14.0-a1 pypi distribution of dbt does not include specific macro directories in its `package_data` list. As a result, dbt installed via pip from pypi does not ship with materialization overrides for archival. This manifests as a `merge` statement running for snapshot jobs on pg/redshift projects.

- [package_data](https://github.com/fishtown-analytics/dbt/blob/dev/wilt-chamberlain/plugins/postgres/setup.py#L24-L29)
- unincluded macros:
  - [postgres](https://github.com/fishtown-analytics/dbt/tree/dev/wilt-chamberlain/plugins/postgres/dbt/include/postgres/macros/materializations)
  - [redshift](https://github.com/fishtown-analytics/dbt/tree/dev/wilt-chamberlain/plugins/redshift/dbt/include/redshift/macros/materializations)

We should:
1. include these macro directories in `setup.py` (is there anywhere else to add them?)
2. figure out if there's a good way to keep these things synchronized, or understand if they've fallen out of sync. This works great in development, but only fails once the release is cut on pypi. Is there a way for us to find this earlier?

### Results
dbt used the default snapshot materialization (using a `merge`) and not the pg/redshift-specific implementation provided in the respective plugins.

### System information
The output of `dbt --version`:
```
0.14.0-a1
```

The operating system you're running on:

The python version you're using (probably the output of `python --version`)

### Steps to reproduce
```
pip install dbt
dbt snapshot # on redshift
```


Discussion:

Resolving patch:
diff --git a/plugins/postgres/setup.py b/plugins/postgres/setup.py
--- a/plugins/postgres/setup.py
+++ b/plugins/postgres/setup.py
@@ -25,6 +25,7 @@
         'dbt': [
             'include/postgres/dbt_project.yml',
             'include/postgres/macros/*.sql',
+            'include/postgres/macros/**/*.sql',
         ]
     },
     install_requires=[
diff --git a/plugins/redshift/setup.py b/plugins/redshift/setup.py
--- a/plugins/redshift/setup.py
+++ b/plugins/redshift/setup.py
@@ -25,6 +25,7 @@
         'dbt': [
             'include/redshift/dbt_project.yml',
             'include/redshift/macros/*.sql',
+            'include/redshift/macros/**/*.sql',
         ]
     },
     install_requires=[


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

Issue:
replace instances of dbt.exceptions with exceptions
## Issue

### Issue description
Some [default implementations of dbt macros](https://github.com/fishtown-analytics/dbt/blob/31f20348c9ffa07cdb00174b66df9ee0ef78cf6e/core/dbt/include/global_project/macros/adapters/common.sql#L226-L229) reference `dbt.exceptions` instead of `exceptions`, leading to errors like
```
'dict object' has no attribute 'exceptions'.
```

In many (all?) of these cases, the macro is raising a "not implemented" exception, so this is a low-impact bug, but one worth fixing for sure.

### Results
dbt raises the incorrect error message

### System information
The output of `dbt --version`:
```
0.13.1
```

### Steps to reproduce
This only really happens when you try to build a new adapter.
1. create a new adapter
2. don't implement methods like `list_relations_without_caching`
3. run dbt


Discussion:
Hi @drewbanin, if I look at this, which branch should I fork from? Apologies if this was addressed in the [contributing](https://github.com/fishtown-analytics/dbt/blob/dev/0.14.1/CONTRIBUTING.md) file and I missed it. Thank you!
Hey @aminamos - our current development branch is `dev/0.14.1`. I'd branch off of there in your fork for the PR!

I'll have a think about how to better document this. Let me know if you have any questions as you dig into it!

Resolving patch:
diff --git a/core/dbt/config/profile.py b/core/dbt/config/profile.py
--- a/core/dbt/config/profile.py
+++ b/core/dbt/config/profile.py
@@ -148,7 +148,6 @@ def __eq__(self, other):
         if not (isinstance(other, self.__class__) and
                 isinstance(self, other.__class__)):
             return False
-            return False
         return self.to_profile_info() == other.to_profile_info()
 
     def validate(self):
diff --git a/core/dbt/exceptions.py b/core/dbt/exceptions.py
--- a/core/dbt/exceptions.py
+++ b/core/dbt/exceptions.py
@@ -646,7 +646,9 @@ def raise_unrecognized_credentials_type(typename, supported_types):
 
 
 def raise_not_implemented(msg):
-    raise NotImplementedException(msg)
+    raise NotImplementedException(
+        "ERROR: {}"
+        .format(msg))
 
 
 def warn_or_error(msg, node=None, log_fmt=None):
@@ -687,6 +689,7 @@ def warn_or_raise(exc, log_fmt=None):
         raise_duplicate_patch_name,
         raise_duplicate_resource_name,
         raise_invalid_schema_yml_version,
+        raise_not_implemented,
         relation_wrong_type,
     ]
 }


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

Issue:
alter-table statements during incremental run leads to potential errors on Snowflake
### Describe the bug
For incremental models, DBT generates the following:

```
alter table <table> add column <col>__dbt_alter character varying(17);

update <table> set <col>__dbt_alter = <col>;

alter table <table> drop column <col> cascade;
```

to accommodate expanding characters in existing columns. This is necessary for Redshift, but Snowflake this is not necessary, as the `string` data type automatically adjusts depending on the data in the table.

In some sense, this could even be thought of as a bug, as this series of commands will fail if the dropped column is part of the cluster key in the table, leading to a failed run.

### Steps To Reproduce
This is baked into an incremental run of DBT.

### System information
- [x] snowflake


**The output of `dbt --version`:**
```
installed version: 0.14.0
   latest version: 0.14.0
```


Discussion:
Thanks for the report @githoov - we'll check it out

Resolving patch:
diff --git a/plugins/bigquery/dbt/adapters/bigquery/impl.py b/plugins/bigquery/dbt/adapters/bigquery/impl.py
--- a/plugins/bigquery/dbt/adapters/bigquery/impl.py
+++ b/plugins/bigquery/dbt/adapters/bigquery/impl.py
@@ -118,6 +118,10 @@ def expand_column_types(self, goal, current):
         # This is a no-op on BigQuery
         pass
 
+    def expand_target_column_types(self, from_relation, to_relation):
+        # This is a no-op on BigQuery
+        pass
+
     def list_relations_without_caching(self, information_schema, schema):
         connection = self.connections.get_thread_connection()
         client = connection.handle


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

Issue:
'SnowflakeConnectionManager' object has no attribute 'nice_connection_name'
dbt makes an errant call to [self.nice_connection_name()](https://github.com/fishtown-analytics/dbt/blob/e7a24a2062704a8effd9d9e1f0fc65ee7fb19aa6/plugins/snowflake/dbt/adapters/snowflake/connections.py#L260), but `nice_connection_name()` is defined on the Adapter, not the Connection Manager.

This bug affects Snowflake on dbt == 0.14.0


Discussion:

Resolving patch:
diff --git a/plugins/snowflake/dbt/adapters/snowflake/connections.py b/plugins/snowflake/dbt/adapters/snowflake/connections.py
--- a/plugins/snowflake/dbt/adapters/snowflake/connections.py
+++ b/plugins/snowflake/dbt/adapters/snowflake/connections.py
@@ -252,12 +252,18 @@ def add_query(self, sql, auto_begin=True,
             )
 
         if cursor is None:
+            conn = self.get_thread_connection()
+            if conn is None or conn.name is None:
+                conn_name = '<None>'
+            else:
+                conn_name = conn.name
+
             raise dbt.exceptions.RuntimeException(
                 "Tried to run an empty query on model '{}'. If you are "
                 "conditionally running\nsql, eg. in a model hook, make "
                 "sure your `else` clause contains valid sql!\n\n"
                 "Provided SQL:\n{}"
-                .format(self.nice_connection_name(), sql)
+                .format(conn_name, sql)
             )
 
         return connection, cursor


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

Issue:
show `database.schema.alias` in CLI output for snapshots
### Describe the feature
Current:
```
22:28:49 | 1 of 1 START snapshot my_snapshot............. [RUN]
22:28:49 | 1 of 1 OK snapshotted my_snapshot............. [INSERT 0 0 in 0.27s]
```

Desired:
```
22:28:49 | 1 of 1 START snapshot snapshot_schema.my_snapshot............. [RUN]
22:28:49 | 1 of 1 OK snapshotted snapshot_schema.my_snapshot............. [INSERT 0 0 in 0.27s]
```

### Who will this benefit?
This output will be more consistent with the output of dbt models, and will better clarify the destination relation for snapshot builds.


Discussion:

Resolving patch:
diff --git a/core/dbt/node_runners.py b/core/dbt/node_runners.py
--- a/core/dbt/node_runners.py
+++ b/core/dbt/node_runners.py
@@ -480,11 +480,14 @@ def after_execute(self, result):
 
 class SnapshotRunner(ModelRunner):
     def describe_node(self):
-        return "snapshot {}".format(self.node.name)
+        return "snapshot {}".format(self.get_node_representation())
 
     def print_result_line(self, result):
-        dbt.ui.printer.print_snapshot_result_line(result, self.node_index,
-                                                  self.num_nodes)
+        dbt.ui.printer.print_snapshot_result_line(
+            result,
+            self.get_node_representation(),
+            self.node_index,
+            self.num_nodes)
 
 
 class SeedRunner(ModelRunner):
diff --git a/core/dbt/ui/printer.py b/core/dbt/ui/printer.py
--- a/core/dbt/ui/printer.py
+++ b/core/dbt/ui/printer.py
@@ -192,14 +192,16 @@ def print_model_result_line(
         result.execution_time)
 
 
-def print_snapshot_result_line(result, index: int, total: int):
+def print_snapshot_result_line(
+    result, description: str, index: int, total: int
+) -> None:
     model = result.node
 
     info, status = get_printable_result(result, 'snapshotted', 'snapshotting')
     cfg = model.config.to_dict()
 
-    msg = "{info} {name}".format(
-        info=info, name=model.name, **cfg)
+    msg = "{info} {description}".format(
+        info=info, description=description, **cfg)
     print_fancy_output_line(
         msg,
         status,


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

Issue:
Better error messaging for malformed source/ref inputs
## Feature

Catch malformed inputs to `source()` and `ref()` functions and elegantly bubble up to end user.

### Current error messaging is non-obvious

had a colleague who is new to dbt encounter the following cryptic error today:
```
__call__() missing 1 required positional argument: ‘table_name’
```
my hunch, knowing a good amount about dbt, was that this was related to a malformed `source()` call, was correct, as he only passed one arg into that fn instead of two:
```
{{ source('some_table') }}
vs
{{ source('my_schema', 'some_table') }}
```
even with the `--debug` flag, this was difficult to track down

### Request

It seems like these sorts of errors could be caught and communicated more effectively (I can't imagine my colleague is the first or last one to make this mistake), to output something like:
```
ERROR: source() function requires two arguments, but received only one
    in models/my_model/some_table.sql (line 51)
    >>>   from {{ source('my_table') }}
```

### Who will this benefit?

This will benefit any user who mistakenly leaves out a schema designation in her `source()` usage, or mistakenly includes a schema designation in a `ref()` call.



Discussion:
Thanks @ryantuck - great idea, and should be straightforward to implement. Is this something you're interested in contributing a fix for?
@drewbanin I'll see how much time I have on a night or a weekend coming up to see what I can do :)
+1

Resolving patch:
diff --git a/core/dbt/context/parser.py b/core/dbt/context/parser.py
--- a/core/dbt/context/parser.py
+++ b/core/dbt/context/parser.py
@@ -108,9 +108,16 @@ def __call__(self, *args):
 
 
 class SourceResolver(dbt.context.common.BaseResolver):
-    def __call__(self, source_name, table_name):
+    def __call__(self, *args):
         # When you call source(), this is what happens at parse time
-        self.model.sources.append([source_name, table_name])
+        if len(args) == 2:
+            self.model.sources.append(list(args))
+
+        else:
+            dbt.exceptions.raise_compiler_error(
+                "source() takes exactly two arguments ({} given)"
+                .format(len(args)), self.model)
+
         return self.Relation.create_from(self.config, self.model)
 
 


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

Issue:
Set upper bound on jsonschema dep
### Describe the bug
With `jsonschema==3.1.0` installed, users see the error:
```
\Z is not valid in Javascript regular expressions - use $ instead (pattern='^[^[0-9][^A-Za-z]][A-Za-z]*\\Z')
```

This error comes from this line of code:
https://github.com/fishtown-analytics/dbt/blob/dev/0.14.1/core/dbt/contracts/project.py#L43

It appears that [jsonschema v3.1.0](https://pypi.org/project/jsonschema/#history) does not support the `\Z` regex token, whereas version 3.0.2 did.

We should either update dbt to be compatible with the 3.1.0 release, or we should pin this dependency to a specific version (like 3.0.2).


Discussion:
I'm adding this to the 0.14.3 release because new installs of dbt are currently bricked.
If you encounter this error, you can fix it by running
```
pip install jsonschema==3.0.2
```
The root issue here was resolved in jsonschema==3.1.1.

Kicking this out of the 0.14.3 milestone and into Louisa May Alcott for a more in-depth triage in the future.
I think we should fix this three ways:

1) Pin 0.14.3 to `jsonschema==3.1.1`, as it appears 3.1.2 will break this again (per [this comment](https://github.com/Julian/jsonschema/issues/612#issuecomment-540151573)) and I don't really want to fix the regex at the last minute in a patch release.
2) Pin the version that `hologram` pulls in to something reasonable (<3.2?) and cut a 0.0.4 release there.
3) Fix our regex to be valid in JS in louisa-may-alcott. The library is technically doing the correct thing, though I do wish the author would have cut this as 4.x since it's a pretty-darn-breaking change. I guess the author only does major revisions for jsonschema draft updates, which is a bummer, but it means we should be pinning to minor releases, not major. That's easy enough to plan around, at least.

Resolving patch:
diff --git a/core/dbt/contracts/project.py b/core/dbt/contracts/project.py
--- a/core/dbt/contracts/project.py
+++ b/core/dbt/contracts/project.py
@@ -16,7 +16,7 @@
 
 
 Name = NewType('Name', str)
-register_pattern(Name, r'^[^\d\W]\w*\Z')
+register_pattern(Name, r'^[^\d\W]\w*$')
 
 # this does not support the full semver (does not allow a trailing -fooXYZ) and
 # is not restrictive enough for full semver, (allows '1.0'). But it's like
diff --git a/core/setup.py b/core/setup.py
--- a/core/setup.py
+++ b/core/setup.py
@@ -54,9 +54,9 @@ def read(fname):
         'agate>=1.6,<2',
         'jsonschema>=3.0.1,<4',
         'json-rpc>=1.12,<2',
-        'werkzeug==0.15.6',
-        'dataclasses;python_version<"3.7"',
-        'hologram==0.0.3',
+        'werkzeug>=0.15,<0.17',
+        'dataclasses==0.6;python_version<"3.7"',
+        'hologram==0.0.4',
         'logbook>=1.5,<1.6',
         'pytest-logbook>=1.2.0,<1.3',
         'typing-extensions>=3.7.4,<3.8',


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

Issue:
Support KMS encryption for BigQuery
### Describe the feature
Allow for KMS encryption to be specified in project configuration. Ideally this would be done in dbt_projects.yml like:
```name: fishtown_analytics

models:
  fishtown_analytics:
  kms_key_name: 'some_kms_key'
  
    events:
      kms_key_name: 'some_other_key' 
```

but may also exist in a model's {{ config() }}

### Describe alternatives you've considered
It may be possible to do this as a post-processing step outside of dbt, or in a post-hook (although I am not aware of any way to specify KMS key in sql).

### Additional context
This feature is specific to BigQuery as it currently stands but may generalize to other databases.

### Who will this benefit?
Anyone who uses BigQuery and may need to encrypt their data with cloud KMS keys (as opposed to the default encryption BigQuery already performs). 



Discussion:
Really neat idea @kconvey!

It looks to me like a `kms_key_name` option can be provided to a `create table as` statement in BigQuery. That would be a good mechanism for dbt to use here I think.

It appears to me that the `kms_key_name` will also need to be supplied when _querying_ this data too. I think that might make it challenging for dbt to use different KMS keys for different models. What happens if you write a query like:
```
select *
from my_dataset.my_first_model
left join my_dataset.my_second_model using (id)
```

If `my_first_model` and `my_second_model` use different KMS keys, which key do you use?

I haven't use KMS on BQ before - if you have insight into how this works in practice, I'd love to hear it!
As a quick note on querying, the KMS key name is not needed when reading tables.  See https://cloud.google.com/bigquery/docs/customer-managed-encryption:

> No special arrangements are required to query a table protected by Cloud KMS. BigQuery stores the name of the key used to encrypt the table content and will use that key when a table protected by Cloud KMS is queried.

> All existing tools, the BigQuery console, and the bq command-line interface run the same way as with default-encrypted tables, as long as BigQuery has access to the Cloud KMS key used to encrypt the table content.

Resolving patch:
diff --git a/plugins/bigquery/dbt/adapters/bigquery/impl.py b/plugins/bigquery/dbt/adapters/bigquery/impl.py
--- a/plugins/bigquery/dbt/adapters/bigquery/impl.py
+++ b/plugins/bigquery/dbt/adapters/bigquery/impl.py
@@ -48,7 +48,8 @@ class BigQueryAdapter(BaseAdapter):
     Column = BigQueryColumn
     ConnectionManager = BigQueryConnectionManager
 
-    AdapterSpecificConfigs = frozenset({"cluster_by", "partition_by"})
+    AdapterSpecificConfigs = frozenset({"cluster_by", "partition_by",
+                                        "kms_key_name"})
 
     ###
     # Implementations of abstract methods


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

Issue:
[LMA Regression] dbt 0.15.0b2 breaks dbt-utils
### Describe the bug
dbt-utils has an `_is_relation` macro. It reports that relations are not relations.

### Steps To Reproduce
1) Pass any valid dbt relation to `dbt_utils._is_relation`
2) Get an exception

### Expected behavior
I expect to not get an error.

### Screenshots and log output
N/A

### System information
**Which database are you using dbt with?**
Any

**The output of `dbt --version`:**
```
installed version: 0.15.0-b2
   latest version: 0.14.3
```

**The operating system you're using:**
Macos Mojave

**The output of `python --version`:**
`3.6.5`

### Additional context
This is caused by `metadata` not being around anymore. I'll have a fix up soon.



Discussion:

Resolving patch:
diff --git a/core/dbt/adapters/base/relation.py b/core/dbt/adapters/base/relation.py
--- a/core/dbt/adapters/base/relation.py
+++ b/core/dbt/adapters/base/relation.py
@@ -43,7 +43,6 @@ def __bool__(self):
         return True
 
     def __getitem__(self, key):
-        # deprecations.warn('not-a-dictionary', obj=self)
         try:
             return getattr(self, key)
         except AttributeError:
@@ -156,6 +155,16 @@ def get_default_include_policy(cls: Type[Self]) -> Policy:
     def get_relation_type_class(cls: Type[Self]) -> Type[RelationType]:
         return cls._get_field_named('type')
 
+    def get(self, key, default=None):
+        """Override `.get` to return a metadata object so we don't break
+        dbt_utils.
+        """
+        if key == 'metadata':
+            return {
+                'type': self.__class__.__name__
+            }
+        return super().get(key, default)
+
     def matches(
         self,
         database: Optional[str] = None,


Test patch:
diff --git a/test/integration/001_simple_copy_test/models/materialized.sql b/test/integration/001_simple_copy_test/models/materialized.sql
--- a/test/integration/001_simple_copy_test/models/materialized.sql
+++ b/test/integration/001_simple_copy_test/models/materialized.sql
@@ -3,6 +3,10 @@
     materialized = "table"
   )
 }}
-
+-- ensure that dbt_utils' relation check will work
+{% set relation = ref('seed') %}
+{%- if not (relation is mapping and relation.get('metadata', {}).get('type', '').endswith('Relation')) -%}
+    {%- do exceptions.raise_compiler_error("Macro " ~ macro ~ " expected a Relation but received the value: " ~ relation) -%}
+{%- endif -%}
 -- this is a unicode character: å
-select * from {{ ref('seed') }}
+select * from {{ relation }}