From 2e4e2a739c327e10461da543f9fb179bab485016 Mon Sep 17 00:00:00 2001 From: Achal Shah Date: Tue, 9 Aug 2022 14:59:39 -0700 Subject: [PATCH] cr Signed-off-by: Achal Shah --- docs/getting-started/concepts/data-ingestion.md | 2 +- docs/getting-started/concepts/feature-repo.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/getting-started/concepts/data-ingestion.md b/docs/getting-started/concepts/data-ingestion.md index e8ca8f6559..3599494f51 100644 --- a/docs/getting-started/concepts/data-ingestion.md +++ b/docs/getting-started/concepts/data-ingestion.md @@ -79,7 +79,7 @@ materialize_bash = BashOperator( -### Batch Data Schema Inference +### Batch data schema inference If the `schema` parameter is not specified when defining a data source, Feast attempts to infer the schema of the data source during `feast apply`. The way it does this depends on the implementation of the offline store. For the offline stores that ship with Feast out of the box this inference is performed by inspecting the schema of the table in the cloud data warehouse, diff --git a/docs/getting-started/concepts/feature-repo.md b/docs/getting-started/concepts/feature-repo.md index e1c4ee8efd..0316019bea 100644 --- a/docs/getting-started/concepts/feature-repo.md +++ b/docs/getting-started/concepts/feature-repo.md @@ -4,10 +4,10 @@ A feature repository is the collection of python files that define entities, feature views and data sources. Feature Repos also have a `feature_store.yaml` file at their root. -Users can collaborate by making and reviewing changes to feast object definitions (feature views, entities, etc) in the feature repo. -But, these objects must be applied, either through API, or the CLI, for them to be available by downstream feast actions (such as materialization, or retrieving online features). Internally, Feast only looks at the registry when performing these actions, and not at the feature repo directly. +Users can collaborate by making and reviewing changes to Feast object definitions (feature views, entities, etc) in the feature repo. +But, these objects must be applied, either through API, or the CLI, for them to be available by downstream Feast actions (such as materialization, or retrieving online features). Internally, Feast only looks at the registry when performing these actions, and not at the feature repo directly. ## Declarative Feature Definitions When using the CLI to apply changes (via `feast apply`), the CLI determines the state of the feature repo from the source files and updates the registry state to reflect the definitions in the feature repo files. -This means that new feature views are added to the registry, existing feature views are updated as necessary, and feast objects removed from the source files are deleted from the registry. \ No newline at end of file +This means that new feature views are added to the registry, existing feature views are updated as necessary, and Feast objects removed from the source files are deleted from the registry. \ No newline at end of file