-
Notifications
You must be signed in to change notification settings - Fork 54
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
feat: add stream methods for Page
#1425
Conversation
Kudos, SonarCloud Quality Gate passed! |
Convert to draft for adding integration tests. |
This reverts commit 6fcfa9b.
Don't merge this yet. We want to control when to introduce this new feature. |
I'll merge main branch into this branch when it's ready to merge. |
Kudos, SonarCloud Quality Gate passed! |
<className>com/google/api/gax/paging/Page</className> | ||
<method>* stream*(*)</method> |
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.
It's strange that CLIRR is complaining the change. Adding default method in interface shouldn't cause a breaking changes.
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.
@JoeWang1127 Just in case, would you build this gax-java locally (with -SNAPSHOT version) and try to use in java-storage to see anything breaks? You ran some storage samples (https://github.com/JoeWang1127/storage-demo) that you used to understand the request.
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.
In Specifying ignored differences of Clirr Maven Plugin doc, 7012 has the following definition:
7012 (Method Added to Interface): className, method
So adding a method to interface, default or not, is a breaking change to this rule.
Also, there's 7013:
7013 (Abstract Method Added to Class): className, method
which is not complain.
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.
Clirr isn't aware of java 8 default methods. It is looking at the bytecode from the perspective of java7 binary compatibility. When adding a default method it is safe to specify an ignore rule.
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.
@BenWhitehead Thanks for the clarification.
@suztomo I've verified the change in the demo project (on branch |
Page
Thank you. |
* fetched whenever the elements of any particular page are exhausted. | ||
*/ | ||
default Stream<ResourceT> streamAll() { | ||
return StreamSupport.stream(iterateAll().spliterator(), false); |
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.
@BenWhitehead Would you elaborate what's not ideal? Parallel Stream.
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.
I think this is great for a first step of getting it on the api and saving our customers from having to do the same hoop jumping.
In the case of future improvements, right now this approach will not allow of parallel processing the same way a natively parallel friendly stream would. In all actuality, Page isn't fully parallelizable due to the fact that each page contains the nextPageToken
necessary in order to fetch the next page. But, Page could be more parallel friendly where processing of the actual resources can happen on a thread separate from the thread performing the actual get.
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.
@JoeWang1127 Do you have question or comment about parallelism? (I don't think of an implementation as of now and don't think we need to implement it right now)
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.
I agree, parallelism does not need to block this PR and can be an additional improvement in the future.
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.
@suztomo I'm not understand about the separate thread in Ben's comment:
Page could be more parallel friendly where processing of the actual resources can happen on a thread separate from the thread performing the actual get.
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.
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.
Thanks for the reference.
I don't have a question about it.
@@ -133,6 +133,54 @@ public void pagedByPage() { | |||
Truth.assertThat(requestCapture.getAllValues()).containsExactly(0, 2, 4).inOrder(); | |||
} | |||
|
|||
@Test | |||
public void streamedByPage() { |
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.
Can we update the test names based on the best practices and a recent TotT?
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.
done
[gapic-generator-java-root] Kudos, SonarCloud Quality Gate passed! |
[java_showcase_integration_tests] SonarCloud Quality Gate failed. |
[java_showcase_unit_tests] Kudos, SonarCloud Quality Gate passed! |
Fixes #1426 ☕️