-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
ObservableCommand with Multiple Values #315
Comments
/cc @KoltonAndrus |
Since generics alone can't solve this (due to type erasure), if we want to support multi-valued responses we likely need another type so we'd end up with:
|
I'm going to keep |
The decisions here affect #302 |
I think the separate class is the way to go. Would |
Hi @spencergibb, thanks for the feedback. Not sure about I'm also curious as to how |
Asking around it seems there is agreement that we should have 2 types:
Are these the correct names and signatures? |
@benjchristensen if you are using |
@spencergibb thanks ... and what do you think about the naming of these two types? Have better ideas? I played around with "Scalar" and "Vector" but don't like those in this context, and feel it's not necessary to say "SingleValued" but need to differentiate the one with "MultiValued" support somehow. If we didn't have the |
I agree, you don't need to call out "SingleValued." My only other thought was "List" because it is called out in |
This change isn't straight-forward. The I can't change that interface as that would break everything. This means something like |
Talking through this with @KoltonAndrus it is apparent that mixing the single/multi-valued paradigms is confusing and dangerous. The key confusion is what to do if a timeout occurs partway through streaming results. What does a fallback mean in that case? Due to this, my proposal is as follows:
This will then support non-blocking, async data sources, and be fully consumable via Rx Observables, but be strictly single-valued. We can then do a v1.5 release where we add something like |
Where this stands:
There's a new issue, scheduled for 1.5, tracking the |
Should a
HystrixObservableCommand
be allowed toonNext
more than 1 value?I would like it to, but it has some challenges.
The
execute()
andqueue()
methods onHystrixObservableCommand
expect a single value, whereasobserve()/toObservable()
can handle multiple.This means the generic type
T
is wrong if theObservable
chooses to return more than one.A
HystrixObservableCommand<T>
would actually need to return like this:List<T> execute()
Future<List<T>> queue()
Observable<T> observe()
But most of the time this would not be wanted, so it would almost necessitate the generics defining it like this:
HystrixObservableCommand<T, List<T>>
orHystrixObservableCommand<T, T>
to keep it scalar.I'm not a fan of either of these.
So should we prohibit multi-valued responses? If so that defeats one of the benefits of
Observable
and the ability to stream a response back, such as using SSE.That said, multi-valued streaming responses also make the concept of timeout a little more confusing ... is it a timeout for the start of a response, or the entire response. I think it should be the entire response (and that's what it is right now).
Right now the code assumes a single generic like
HystrixObservableCommand<T>
and allows multi-valued responses when usingobserve()/toObservable()
but will blow up ifexecute()
orqueue()
are used like this (shortened):I'd appreciate input on what direction to take this.
The text was updated successfully, but these errors were encountered: