can you add type on all public vals/defs?

very cool. Glad to see twttr is picking up on json4s. I'm a fan of a common (ast) interface that you can swap out backends for :)

Should nodes be a List[(String, Int)]?

Still learning about elasticsearch architecture. I'm wondering if there are ever cases where two instances run on the same host.

What do you think about moving this to storehaus-core? There can possibly be a mysql version of this.

I am fine with that as long as @johnynek is cool with that. I suspect he will ask me to change some things around. In addition to MySql we can potentially use QueryableStore for HBase and Mongo as well

can you make this: QueryableStore[-Q, +V]? I don't see the need to force this to be a subclass of Store[K, V] (for instance, I can't write to Google, but I can query it).

Also, and I think Avi asked this, what is the main difference here to: Readable[Q, Seq[V]]

Lastly, if we are in the business of making new traits, why not make this: query(q: Q): Future[Seq[V]]?

Whatever we decide here should definitely be in storehaus-core.

My preference is to add a method to do something like:

def queryable: Readable[Q, Seq[V]]

longer term, getting something like the Spool in the value might be the right thing, but I am skeptical of large async requests.

Is this safe to call from different threads? Link to docs allowing that?

Just a thought - if we are going to use ReadableStore, can we just make this:

trait QueryableStore[Q, V] extends ReadableStore[Q, Seq[V]]

hmm I am not sure about that. To me QueryableStore produces a ReadableStore but is not a ReadableStore itself.

Ok makes sense. I can see the goal for having this trait as a kind of factory class -- enabling a store to produce a queryable version of itself.

(Was just wondering if there is a way to avoid a layer of indirection here if we thought of a queryable store as a ReadableStore that represents a map from Query to Seq[V]. But I guess there's no good way to achieve the above goal if we go down this path.)

Alternatively, can there be a combinator for this?

class QueryableStore[Q, K, V](store: ReadableStore[K, V])
  extends ReadableStore[Q, Seq[V])

Sorry, just trying to be useful :)

Let's make it covariant to match store.
trait QueryableStore[Q, +V]

Q could possibly be made contra variant, but it a bit of a pain due to the way we are returning a store. Also, queries are less likely to be subclassed. I'd leave that as is.

since the bijection code got merged, can we make this private so we don't get a binary incompatibility when we remove it?

I want to publish this week. That or we can get bijection out today, and then fix this up tomorrow or thurs?

If you can push bijection out today, I can make the change by tomorrow. Let
me know if this works

On Tue, Feb 4, 2014 at 1:54 PM, P. Oscar Boykin [email protected]:

In
storehaus-elasticsearch/src/main/scala/com/twitter/storehaus/elasticsearch/Injections.scala:

+import scala.util.Try
+import org.json4s._
+import native.JsonMethods._
+import com.twitter.bijection.Inversion.attempt
+import native.Serialization.{write, read}
+import com.twitter.algebird.Monoid
+import org.json4s.JValue
+import com.twitter.algebird.
bijection.BijectedMonoid
+
+
+/**

• * Temporary home of Json algebra. Will be removed once Json4s bijections get merged in twitter-bijections
• * @author Mansur Ashraf
• * @SInCE 1/8/14
• */
  +object Injections {

since the bijection code got merged, can we make this private so we don't
get a binary incompatibility when we remove it?

I want to publish this week. That or we can get bijection out today, and
then fix this up tomorrow or thurs?

Reply to this email directly or view it on GitHubhttps://github.com//pull/205/files#r9435670
.

these whitespace/comment only changes are not ideal. Please try to keep the diff as focused as possible on the functional bits. This makes it easier to miss meat in a code review.