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

fix: cache handling on update #604

Merged
merged 8 commits into from
Oct 20, 2021
Merged

fix: cache handling on update #604

merged 8 commits into from
Oct 20, 2021

Conversation

csviri
Copy link
Collaborator

@csviri csviri commented Oct 14, 2021

No description provided.

@csviri csviri marked this pull request as ready for review October 15, 2021 09:08
@csviri csviri requested review from lburgazzoli and metacosm and removed request for lburgazzoli October 15, 2021 09:08
return true;
}
String originalResourceVersion = getVersion(executionScope.getCustomResource());
String customResourceVersionAfterExecution = getVersion(postExecutionControl
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't like how we access an Optional without checking if it's present or not. If we never check for the presence, we might as well not use an Optional.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is quite a gray are, because we are checking implicitly above. So returning when there was no execution:

   if (!postExecutionControl.customResourceUpdatedDuringExecution()) {
      return true;
    }

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's not nice, but not sure how we could make it nicer.

String customResourceVersionAfterExecution = getVersion(postExecutionControl
.getUpdatedCustomResource().get());
String cachedCustomResourceVersion = getVersion(resourceCache
.getCustomResource(executionScope.getCustomResourceID()).get());
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same as above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Same here, so we know that in this case by definition there should be a custom resource in the cache. We are checking this elsewhere where it acutally might not be true.
I can comment it in the code.

Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe the method should be changed to receive the custom resources instead of ExecutionScope & PostExecutionControl so the invocation could be closed where the check on the optional value presence are performed ??

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Will take a look. But though that just throwing an exception with orElseThrow would be also a way to go, since that situation should not happen here. And this way it's quite readable. What do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't have any strong opinion to be honest so either way is ok with me.
Usually I find easier to reason and test where there's not so much indirection but again, no strong opinions here :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

pushed it with the mentioed way. I don't like it either. At some point we might want to rethink and/or refactor those core classes. To much complexity in one place :/

Copy link
Collaborator

Choose a reason for hiding this comment

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

pushed it with the mentioed way. I don't like it either. At some point we might want to rethink and/or refactor those core classes. To much complexity in one place :/

Well, v2 is the time to do it, I would say 😄

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@metacosm yes, but could we do it as a separate PR, since this is just thiss feature, and that would have effect on everything else.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It seems that the serverless support will require some fundamental changes.

@csviri csviri requested a review from metacosm October 20, 2021 08:06
@csviri csviri merged commit b278ebf into v2 Oct 20, 2021
@csviri csviri deleted the update-cache-optimization branch October 20, 2021 13:49
metacosm added a commit that referenced this pull request Oct 28, 2021

Co-authored-by: Chris Laprun <metacosm@gmail.com>
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.

Caching just Updated Custom Resource Optimization alternatives
3 participants