Firming up Results

[hamiltop]

Results should support the following:

1. Raw result (not an ORM)
2. Feeds are Enumerable
3. Some mechanism for a supervised feed should be possible (documented, but doesn't have to be provided by this lib)
4. All ReQL result types should be handled and present in a "User Friendly" way. ie things like ResponseNotes should be an implementation detail and not leaked out.

I'm fairly committed to returning a struct with a data field that provides the raw data response. This should mirror what is returned in the "Data Explorer" of rethinkdb. However, the struct can and should contain other information (token, response note, etc) but those should be hidden from the end user except in error messages (we'll want them for bug fixing).

Feeds should be Enumerable as that will be the simplest way to interact with them. I'm not convinced that Enumerable is the best approach to consuming feeds in production.

I'd like someone to explore supervised feeds. We will most likely not include them in 1.0.0, but I want to make sure we aren't painting ourselves into a corner. If we could document a simple way to have a supervised feed it would suffice.

Some result types are weird. There are a bunch of error results and any result of type PARTIAL (a feed) has a ResponseNote that describes the response. (see "Receive Responses" in http://rethinkdb.com/docs/writing-drivers/ ) Some of these, like ORDER_BY_LIMIT_FEED are sort of an odd duck. The user should know that the response has different semantics (ie, old_val is the record that is booted from the result set. It was not overwritten by new_val on the server side). The user experience should match at a minimum what is expected in the official drivers.

[Linicks]

@hamiltop,

• "Feeds should be Enumerable as that will be the simplest way to interact with them. I'm not convinced that Enumerable is the best approach to consuming feeds in production."

  As I was reading this issue I was thinking about the Streams-Lazy Enumerables section of the Programming Elixir book starting on page 93. In that section of the book Dave talks about the greedy behavior of the Enum module, and how you can deal with large data-sets by Enumerating a Stream since they are lazy. Is there any correlation to this technique, and how you are handling results/responses from the database?

[hamiltop]

You don't implement Streams or Enums. You implement the Enumerable Protocol and the developer can choose whether to consume via Stream or Enum in order to choose whether to be eager or lazy.

Currently, this works as designed.

[hamiltop]

I think this is pretty much done. A few individual tickets remain, but I'm closing this.