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

Added read_data and enforce_data parameters #177

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

Conversation

pruiz
Copy link

@pruiz pruiz commented Jun 10, 2022

This PR adds two features:

  • read_data => Allows specifying a 'data/body' to send along with read requests.
  • enforce_data => which ensures re-creation of object in cases where it ends up with some attribute different from the ones initially used to create it (as defined at 'data')

Regards
Pablo

@@ -299,6 +322,17 @@ func resourceRestAPIExists(d *schema.ResourceData, meta interface{}) (exists boo
err = obj.readObject()
if err == nil {
exists = true
if enforce, ok := d.GetOk("enforce_data"); ok && enforce.(bool) {
Copy link
Member

Choose a reason for hiding this comment

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

This makes a lot of sense and is something that I've wanted to add to the provider for quite some time. Unfortunately, this particular implementation falls a bit short because it is only examining first-level child objects to detect differences. I think there needs to be a more "deep" diff that happens

Also, this is expected behavior with Terraform, so we shouldn't require a new parameter.

Choose a reason for hiding this comment

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

@DRuggeri would you consider accepting just the read_data portion? I have a project I’m working on that needs a POST call when reading. Currently when using the provider and doing a POST on read_method the application will error because no json payload is sent even when the app just expects an empty dictionary.

Would you prefer it gets split off of this pull request to implement this? I can go through the changes and submit a new one with just that.

Copy link
Member

Choose a reason for hiding this comment

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

Apologies for the delay, @Xboarder56!

Yes, read_data is OK and, in the time since the PR was opened and I've been able to dig into feature reviews again, #252 was opened. Definitely happy to have read_data!

@shmyer
Copy link

shmyer commented Sep 14, 2023

Hi, are there plans to support the read_data parameter in the near future?

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.

4 participants