You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working with Python and Protobuf, the normal relationship is that .proto files are defined, converted to Python classes by the proto compiler, and then integrated into Python code by importing the compiled proto classes. For simple logging events this will probably work fine.
But in some cases we are going to want to provide a lot more data, up to and including an almostly complete serialization of node contents. Defining nodes first in proto files would be really difficult, particularly considering the somewhat complex class hierarchy for various node and node config classes. We will need to decide how to handle these more complicated classes, whether by some kind of field metadata and generating proto classes, or parallel but tested creation of both proto files and our existing Python classes, or creating utility functions that generate a proto based object from a node object.
In addition, we are going to need to have the proto compiler available at development time, but it should never be required at run time or for the installation of dbt core as an application. So we need to specify it as a dev requirement.
Part of this spike is also to come up with policies for handling the event codes, the proto schemas, the naming of the relevant fields, possible simplifying of the existing schemas (i.e. do we need an event "type"...). In addition we will have to come up with a standard way of importing the proto based event classes and instantiating them in our Python code. For example, proto definitions cannot have defaults, so the actual code can't be specified in a proto file. Do we subclass every proto generated class? Where/how do we set the codes for the events? And other issues like that.
The goal of this spike is that at the end of it we have a path forward so that we can start converting all of the existing events.
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
[SPIKE] Investigate options for creating proto files for dbt-core events
[CT-986] [SPIKE] Investigate options for creating proto files for dbt-core events
Aug 3, 2022
When working with Python and Protobuf, the normal relationship is that .proto files are defined, converted to Python classes by the proto compiler, and then integrated into Python code by importing the compiled proto classes. For simple logging events this will probably work fine.
But in some cases we are going to want to provide a lot more data, up to and including an almostly complete serialization of node contents. Defining nodes first in proto files would be really difficult, particularly considering the somewhat complex class hierarchy for various node and node config classes. We will need to decide how to handle these more complicated classes, whether by some kind of field metadata and generating proto classes, or parallel but tested creation of both proto files and our existing Python classes, or creating utility functions that generate a proto based object from a node object.
In addition, we are going to need to have the proto compiler available at development time, but it should never be required at run time or for the installation of dbt core as an application. So we need to specify it as a dev requirement.
Part of this spike is also to come up with policies for handling the event codes, the proto schemas, the naming of the relevant fields, possible simplifying of the existing schemas (i.e. do we need an event "type"...). In addition we will have to come up with a standard way of importing the proto based event classes and instantiating them in our Python code. For example, proto definitions cannot have defaults, so the actual code can't be specified in a proto file. Do we subclass every proto generated class? Where/how do we set the codes for the events? And other issues like that.
The goal of this spike is that at the end of it we have a path forward so that we can start converting all of the existing events.
The text was updated successfully, but these errors were encountered: