DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Deprecation Warning
The content of this page is now deprecated. With the work being done in AIP-103, this is no longer necessary. It is being stored here so it can be removed (safely) from the parent page.
Technical Details
Stage 1 - Building the generic StateVariable model
Building the async-aware StateVariable model would require minimal lift. Like the Variable model, this would be “unrelated” to other models, making the creation a bit easier. Such model should be usable by various Airflow components, other than triggers. Therefore, it should provide an abstraction layer that
This model contains two core fields: key and value. Below is the pseudo-code for the StateVariable model.
class StateVariable:
"""
StateVariable class allows various methods fetching and storing values.
"""
key: str
value: str
def set(self, key, value):
# Using db connection as an example here, this method will vary
db_backend.set_value(key=key, value=value)
def get(self):
return db_backend.get_value(key=key)
Despite their similarities, StateVariable will differ from Variable in a number of ways. These include:
StateVariablewill NOT use a traditional Secrets Backend. Instead, it will have its own type of backend.StateVariablewill have its own UI component(s), and can be integrated more "natively" into a DAG/Asset Watcher.StateVariablewill have a sort of "owner" field, something thatVariabledoes not have.
Stage 2 - Extending the backend of StateVariable
The state model will be reusable and extendable in other Airflow components, such as task, worker, scheduler, etc. It should support not only the API, but also the Task SDK for fetching and storing the value for different components.
Stage 3 - Implement the state-enabled Trigger/Asset Watcher
Once the StateVariable model has been created, it can be used within a BaseEventTrigger just like Variable would; using StateVariable.get() and StateVariable.set(...) . This pattern is quite intuitive for DAG authors.
It would require some sort of get and set logic to be implemented in a class that inherits from BaseEventTrigger in order to store and retrieve watermark value. This could be used in a standalone manner, or be implemented in the form of a "helper" method in the BaseEventTrigger class.