Skip to main content
Version: 0.9

Use prevent_destroy to Protect Production Pipelines and Services

Tecton recreates repo objects when certain fields are changed. For example, changing the SQL transformation in a Feature View would by default cause Tecton to recreate that Feature View. Recreates are destructive, so for Feature Views with materialized tables, Tecton will rematerialize those tables and clean up the old tables. During this time, those Feature Views will not be available for online serving.

See Making Changes to Features for a guide on how to safely make changes to Tecton objects and avoid destructive changes.

If you would like a Tecton object to never be accidentally recreated or destroyed (i.e. deleted), you can set the prevent_destroy parameter on that object. This will prevent that Tecton object from being recreated or destroyed. Also, since destructive changes cascade to dependent objects, setting prevent_destroy will block destructive changes on all inputs. For example, setting prevent_destroy on a Feature Service will block destructive changes on all Feature Views that that service depends on.

@batch_feature_view(
sources=[FilteredSource(transactions_batch)],
entities=[user],
mode="spark_sql",
online=True,
offline=True,
feature_start_time=datetime(2021, 5, 20),
batch_schedule=timedelta(days=1),
prevent_destroy=True,
)
def critical_feature_view(transactions):
pass


critical_feature_service = FeatureService(
name="my_critical_service",
features=[critical_feature_view],
prevent_destroy=True,
)
info

prevent_destroy has no effect in development workspaces, as there are no assets or processes to protect.

Typical Uses​

prevent_destroy is most commonly used on Feature Views and Feature Services for the following reasons:

  1. Prevent serving downtime by setting prevent_destroy on production Feature Services.
    • Feature Services with prevent_destroy set will prevent recreates of any Feature Views used in the Feature Service.
  2. Avoid accidentally rematerializing large Feature Views, even if they're not used in production.
    • If a Feature View is expensive to materialize (e.g. it transforms years of data) consider enabling prevent_destroy for that Feature View even if it's not used in production applications.
  3. Prevent schema changes to Feature Services or Feature Views.
    • Schema changes to Feature Services and Views are always destructive. If a downstream application depends on the exact schema of Feature Service or View, then prevent_destroy may be used to ensure that the schema does not change accidentally.

Deleting Protected Objects​

If you want to delete a protected object, you must first set prevent_destroy to False, apply that plan, and then apply a second plan to remove the object.

Was this page helpful?