Skip to content
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

[Feature] WIP: Allow to skip calling Read after Create/Update operations #4173

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alexott
Copy link
Contributor

@alexott alexott commented Oct 30, 2024

Changes

This PR adds the ability for a resource to specify that it may not need to call Read after Create and Update operations so we can avoid performing another API call(s). The resource may implement CanSkipReadAfterCreateAndUpdate function that can decide if the Read operation should be skipped.

It was found that the import API returns object_id as a result of its execution, so we don't really need to call get-status to fill all attributes. This should help when we import a large number of notebooks, i.e., when applying exported resources.

TODOs:

  • add unit test for a test resource that implements skipping
  • check if we need to have a suppress diff for the language attribute
  • add integration tests for DBC/Jupyter create and update

Tests

  • make test run locally
  • relevant change in docs/ folder
  • covered with integration tests in internal/acceptance
  • relevant acceptance tests are passing
  • using Go SDK

@alexott alexott requested review from a team as code owners October 30, 2024 12:21
@alexott alexott requested review from rauchy and removed request for a team October 30, 2024 12:21
@alexott alexott requested a review from mgyucht October 30, 2024 12:21
workspace/resource_notebook.go Outdated Show resolved Hide resolved
}
if err != nil {
return err
}
}
d.Set("object_id", resp.ObjectID)
d.Set("skip_get_status", true)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of adding this to the databricks_notebook schema, can we add it to common.Resource when defining the resource? Basically, we can change the create method to:

		resource.CreateContext = func(ctx context.Context, d *schema.ResourceData, m any) diag.Diagnostics {
			c := m.(*DatabricksClient)
			err := recoverable(r.Create)(ctx, d, c)
			if err != nil {
				err = nicerError(ctx, err, "create")
				return diag.FromErr(err)
			}
			if r.SkipReadAfterCreateAndUpdate {
				return nil
			}
			if err = recoverable(r.Read)(ctx, d, c); err != nil {
				err = nicerError(ctx, err, "read")
				return diag.FromErr(err)
			}
			return nil
		}

and same for update.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let me look

@alexott alexott changed the title [Fix] Skip calling get-status for notebooks in Read after Create/Update operations [Feature] Allow to skip calling Read after Create/Update operations Oct 30, 2024
@alexott alexott changed the title [Feature] Allow to skip calling Read after Create/Update operations [Feature] WIP: Allow to skip calling Read after Create/Update operations Oct 30, 2024
This PR adds the ability for a resource to specify that it may not need to call
`Read` after `Create` and `Update` operations so we can avoid performing another
API call(s). The resource may implement `CanSkipReadAfterCreateAndUpdate` function
that can decide if the Read operation should be skipped.

It was found that the import API returns `object_id` as a result of its execution,
so we don't really need to call get-status to fill all attributes.
This should help when we import a large number of notebooks, i.e., when applying exported resources.
@eng-dev-ecosystem-bot
Copy link
Collaborator

Test Details: go/deco-tests/11598800362

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants