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

Paged Flux abstractions #6465

Merged
merged 43 commits into from
Jan 17, 2020
Merged

Paged Flux abstractions #6465

merged 43 commits into from
Jan 17, 2020

Conversation

anuchandy
Copy link
Member

No description provided.

@anuchandy anuchandy changed the title PagedFluxCore as an abstraction for generic paging (not tied to protocol e.g. http) Paged Flux abstractions Nov 24, 2019
@anuchandy anuchandy marked this pull request as ready for review November 26, 2019 18:44
@anuchandy anuchandy requested a review from mssfang as a code owner November 26, 2019 19:50
…as PagedFlux, this will help us from not exposing more-more flux operator on PagedFlux, enable Continuation-option in base abstract type
@anuchandy
Copy link
Member Author

anuchandy commented Dec 11, 2019

@JonathanGiles we talked about identifying the places where mapPage is used: It is used only by Data Lake SDK at the moment

@alzimmermsft
Copy link
Member

Would this handle only requesting 1 page at a time and not trigger subsequent page requests? #6518

…ontinuationState.java

Co-Authored-By: Alan Zimmer <48699787+alzimmermsft@users.noreply.github.com>
@anuchandy
Copy link
Member Author

@alzimmermsft Would this handle only requesting 1 page at a time and not trigger subsequent page requests: its configurable in the ContinuablePagedFluxCore Ctr through prefetch argument. If not specified we default to the reactor prefetch.

@anuchandy anuchandy requested a review from joshfree as a code owner January 5, 2020 22:02
Copy link
Member

@srnagar srnagar left a comment

Choose a reason for hiding this comment

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

I have a few comments about docs and minor changes. Otherwise, looks great!

*/
List<T> getItems();

public interface Page<T> extends ContinuablePage<String, T> {
Copy link
Member

Choose a reason for hiding this comment

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

Yes, because we have a released version already, we'll have to keep this hierarchy.

* This class is a flux that can operate on a {@link PagedResponse} and also provides the ability to operate on
* individual items. When processing the response by page, each response will contain the items in the page as well as
* the request details like status code and headers.
* This type is a Flux provides the ability to operate on paginated REST response of type {@link PagedResponse}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* This type is a Flux provides the ability to operate on paginated REST response of type {@link PagedResponse}
* This type is a {@link Flux} that provides the ability to operate on paginated REST response of type {@link PagedResponse}

// 2. Add a new ctr "PagedFlux(Supplier<PageRetriever<String, PagedResponse<T>>>)".
// 3. Remove the factory method "PagedFlux::create" and this PRIVATE ctr in favour of #2.
//
private PagedFlux(Supplier<PageRetriever<String, PagedResponse<T>>> provider, boolean ignored) {
Copy link
Member

Choose a reason for hiding this comment

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

Agree. Maybe this can be tracked in a github issue with appropriate labels so we don't forget to make this change when working on a major version release.

*/
List<T> getItems();

public interface Page<T> extends ContinuablePage<String, T> {
Copy link
Member

Choose a reason for hiding this comment

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

@anuchandy Can you please be sure to update #6610 with the final set of changes we would make when a breaking-change release is possible.

default List<T> getItems() {
IterableStream<T> iterableStream = this.getElements();
return iterableStream == null
? null
Copy link
Member

Choose a reason for hiding this comment

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

Could we not return an empty IterableStream rather than null here, to be doubly protective of the end user?

// 2. Add a new ctr "PagedFlux(Supplier<PageRetriever<String, PagedResponse<T>>>)".
// 3. Remove the factory method "PagedFlux::create" and this PRIVATE ctr in favour of #2.
//
private PagedFlux(Supplier<PageRetriever<String, PagedResponse<T>>> provider, boolean ignored) {
Copy link
Member

Choose a reason for hiding this comment

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

We will unfortunately need to live with this inconsistency until we can do a breaking change release. The only positive is that we don't expect end users to be dealing with this API, so the only people encountering this will be client library developers.

public List<T> getItems() {
return items;
public IterableStream<T> getElements() {
return items == null
Copy link
Member

Choose a reason for hiding this comment

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

I agree with Alan

public List<ConfigurationSetting> getItems() {
return items;
public IterableStream<ConfigurationSetting> getElements() {
return items == null ? IterableStream.empty() : new IterableStream<>(items);
Copy link
Member

Choose a reason for hiding this comment

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

Could introduce IterableStream.of(List) or similar to avoid null checks in these cases.

Copy link
Member Author

Choose a reason for hiding this comment

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

added IterableStream.of(Iterable<T>) factory method: if parameter to this factory is null then it return cached static empty stream otherwise it create a new IterableStream from the parameter.

Copy link
Member

@JonathanGiles JonathanGiles left a comment

Choose a reason for hiding this comment

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

LGTM. Let's get this into azure-core and have a beta release in February to test it out. @hemanttanwar We don't want the february release to be a GA release of azure core.

@anuchandy
Copy link
Member Author

@hemanttanwar - Couple of client-lib pom are updated to refer "unreleased version of azure_core" which has pagination improvements. Could you please take a look at those and if all good let's get this in.

@anuchandy anuchandy requested review from hemanttanwar and removed request for hemanttanwar January 17, 2020 03:28
Copy link
Contributor

@hemanttanwar hemanttanwar left a comment

Choose a reason for hiding this comment

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

Like we spoke about it, Just run update_version script to make sure there are no more changed needed in pom files.

@anuchandy
Copy link
Member Author

@hemanttanwar thanks, as discussed I ran the following command on this changes:

python eng/versioning/update_versions.py --ut library --bt client --sr

and it didn't update any pom files which indicates that the current changes are correct.

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.

6 participants