Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Move `ColumnInfo` to dbt/artifacts * Move `Quoting` resource to dbt/artifacts * Move `TimePeriod` to `types.py` in dbt/artifacts * Move `Time` class to `components` We need to move the data parts of the `Time` definition to dbt/artifacts. That is not what we're doing in this commit. In this commit we're simply moving the functional `Time` definition upstream of `unparsed` and `nodes`. This does two things - Mirrors the import path that the resource `time` definition will have in dbt/artifacts - Reduces the chance of ciricular import problems between `unparsed` and `nodes` * Move data part of `Time` definition to dbt/artifacts * Move `FreshnessThreshold` class to components module We need to move the data parts of the `FreshnessThreshold` definition to dbt/artifacts. That is not what we're doing in this commit. In this commit we're simply moving the functional `FreshnessThreshold` definition upstream of `unparsed` and `nodes`. This does two things - Mirrors the import path that the resource `FreshnessThreshold` definition will have in dbt/artifacts - Reduces the chance of ciricular import problems between `unparsed` and `nodes` * Move data part of `FreshnessThreshold` to dbt/artifacts Note: We had to override some of the attrs of the `FreshnessThreshold` resource because the resource version only has access to the resource version of `Time`. The overrides in the functional definition of `FreshnessThreshold` make it so the attrs use the functional version of `Time`. * Move `ExternalTable` and `ExternalPartition` to `source_definition` module in dbt/artifacts * Move `SourceConfig` to `source_definition` module in dbt/artifacts * Move `HasRelationMetadata` to core `components` module This is a precursor to splitting `HasRelationMetadata` into it's data and functional parts. * Move data portion of `HasRelationMetadata` to dbt/artifacts * Move `SourceDefinitionMandatory` to dbt/artifacts * Move the data parts of `SourceDefinition` to dbt/artifacts Something interesting here is that we had to override the `freshness` property. We had to do this because if we didn't we wouldn't get the functional parts of `FreshnessThreshold`, we'd only get the data parts. Also of note, the `SourceDefintion` has a lot of `@property` methods that on other classes would be actual attribute properties of the node. There is an argument to be made that these should be moved as well, but thats perhaps a separate discussion. Finally, we have not (yet) moved `NodeInfoMixin`. It is an open discussion whether we do or not. It seems primarily functional, as a means to update the source freshness information. As the artifacts primarily deal with the shape of the data, not how it should be set, it seems for now that `NodeInfoMixin` should stay in core / not move to artifacts. This thinking may change though. * Refactor `from_resource` to no longer use generics In the next commit we're gonna add a `to_resource` method. As we don't want to have to pass a resource into `to_resource`, the class itself needs to expose what resource class should be built. Thus a type annotation is no longer enough. To solve this we've added a class method to BaseNode which returns the associated resource class. The method on BaseNode will raise a NotImplementedError unless the the inheriting class has overridden the `resouce_class` method to return the a resource class. You may be thinking "Why not a class property"? And that is absolutely a valid question. We used to be able to chain `@classmethod` with `@property` to create a class property. However, this was deprecated in python 3.11 and removed in 3.13 (details on why this happened can be found [here](python/cpython#89519)). There is an [alternate way to setup a class property](python/cpython#89519 (comment)), however this seems a bit convoluted if a class method easily gets the job done. The draw back is that we must do `.resource_class()` instead of `.resource_class` and on classes implementing `BaseNode` we have to override it with a method instead of a property specification. Additionally, making it a class _instance_ property won't work because we don't want to require an _instance_ of the class to get the `resource_class` as we might not have an instance at our dispossal. * Add `to_resource` method to `BaseNode` Nodes have extra attributes. We don't want these extra attributes to get serialized. Thus we're converting back to resources prior to serialization. There could be a CPU hit here as we're now dictifying and undictifying right before serialization. We can do some complicated and non-straight-forward things to get around this. However, we want to see how big of a perforance hit we actually have before going that route. * Drop `__post_serialize__` from `SourceDefinition` node class The method `__post_serialize__` on the `SourceDefinition` was used for ensuring the property `_event_status` didn't make it to the serialized version of the node. Now that resource definition of `SourceDefinition` handles serialization/deserialization, we can drop `__post_serialize__` as it is no longer needed. * Merge functional parts of `components` into their resource counter parts We discussed this on the PR. It seems like a minimal lift, and minimal to support. Doing so also has the benefit of reducing a bunch of the overriding we were previously doing. * Fixup:: Rename variable `name` to `node_id` in `_map_nodes_to_map_resources` Naming is hard. That is all. * Fixup: Ensure conversion of groups to resources for `WritableManifest`
- Loading branch information