-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: First pass at documenting schema evolution features #1259
Conversation
Updates some existing concepts pages to add docs on new schema evolution features. Also adds a new concepts page on evolutions, and a new guide outlining how to handle some common schema evolution scenarios.
|
51c76c0
to
9b662f7
Compare
* **In the Flow web app,** [edit the materialization](./edit-data-flows.md#edit-a-materialization), find the affected binding, and click **Show Fields**. | ||
* **Using flowctl,** add the field to `fields.include` in the materialization specification as shown [here](../concepts/materialization.md#projected-fields). | ||
|
||
### A field's data type has changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@psFried would the UI show that schema evolution dialog option (like with the changed key & projections) in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, it depends on whether or not the connector permits the change. If the connector says it's OK, then we won't show any errors or an evolution dialog. But if the connector rejects the change, then we will. It can be a little nuanced, but some general guidelines are:
- materializations to S3 or webhooks will generally tolerate most any change
- database materializations will generally reject most changes to materialized columns, except for dropping
NOT NULL
constraints - If a given field isn't part of the field selection, then any change will be allowed by the connector (even if it's not a good idea for other reasons)
But yeah, probably the most common scenario would be that changing a field type would result in the UI showing the schema evolution dialog.
Updates some existing concepts pages to add docs on new schema evolution features. Also adds a new concepts page on evolutions, and a new guide outlining how to handle some common schema evolution scenarios.
Keeping this as a draft for now, so we can look at the preview and iterate.
This change is