IssueTracker

Why a Maybe<T> instead of `Flowable<Optional<T>>? I'd want this to be a hot stream (keep the steam alive). We should be able to provide our own custom converter/adapter here to use our desired Optional type.

When observing a database record, you usually don't want the steam to terminate (onComplete() is a terminal event)

The problem is that, which Optional? :)
We thought about adding support for guava optional but a small (unofficial, unscientific) survey w/ external developers showed that most use their own optional.

We didn't want to create 1 more but maybe we will. Which Optional class are you using?

The intent with this issue as stated above was to support single emissions
from queries with Maybe. I guess in a way that might encompass "optionals"
but really we just need a way to have queries with no results not filtered
before making it downstream. Maybe support is the candidate for getting to
that for these type of one off queries.

On Thu, Jul 6, 2017, 11:25 AM <buganizer-system@google.com> wrote:

> The intent with this issue as stated above was to support single emissions
from queries with Maybe

With a `Flowable<Optional<T>()`, you can easily convert it to a `Maybe<T>`. `Flowable<Optional<T>()` is the ultimately flexible type, which is one of the selling points of Rx. `.onComplete()` is not a substitute for a lack of value.

> We didn't want to create 1 more but maybe we will. Which Optional class are you using?

My own (survey on point)! Mostly equivalent to https://github.com/gojuno/koptional (Kotlin's optional as a sealed class has advantages). Maybe each library should create its own Optional (which we can then convert into our own types)? I'd recommend not calling it `Optional`, but maybe something like `RoomOptional<T>` or `RoomRecord<T>`. The idea is to avoid thirteen different `Optional`s on the classpath and other devs choosing the wrong one.

I haven't used Room much yet, but an empty list does indicate no values returned (which we could map to our own optional later). Note -> I wouldn't want my `Dao` interface to expose the empty list for a single value, but my own optional type. This part can get a little messy. But I also wouldn't want my `Dao` interface to expose Room's optional type (I'd want it to expose my own).

Would it be possible for us to supply a third party `Optional` adapter to room for our own optional type? Similar to what Retrofit does with its RxJava2 Call adapter?

+1 to Flowable emitting an empty List

+1 to Kyle's point, if you run a query for a single element and it doesn't come back Maybe seems like the most appropriate response (https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#maybe). As the onComplete represents a 0 (from the options of 0 or 1). I think for events where you want a Single responses this is a solid API choice.

As for the Infinite stream of a single objects, I agree with Zak's approach.

shipped maybe and single in alpha 5.
Zak, for a Flowable<Optional<T>> solution, i think we'll wait for now mostly because it can easily be solved by Flowable<List<T>>.
We have some plans to allow compile time plugins, which will probably be the right way to add such customizations. (post 1.0).