Skip to content
This repository has been archived by the owner on Feb 15, 2022. It is now read-only.

Reconsider get/getCounter and scan/scanCounters #4

Open
plaflamme opened this issue Jun 9, 2015 · 0 comments
Open

Reconsider get/getCounter and scan/scanCounters #4

plaflamme opened this issue Jun 9, 2015 · 0 comments

Comments

@plaflamme
Copy link
Owner

Having get/getCounter makes interacting with cockroach a lot easier since you normally know what type of value you're expecting (i.e.: bytes or counter).

That said, calling one version on the wrong type currently succeeds and returns a None. That's probably undesirable.

Similarly, scan and scanCounters currently skip values of the wrong type. If a client needs to scan both, this is inefficient.

This can be solved by introducing a Value type that has a Bytes and Counter implementation. Consider this signature:

sealed trait Value
case class BytesValue(bytes: Bytes) extends Value
case class CounterValue(value: Long) extends Value

class Client {
  def get(key: Bytes): Future[Option[Value]]
  def getBytes(key: Bytes): Future[Option[Bytes]] // fails when reading a counter
  def getCounter(key: Bytes): Future[Option[Long]] // fails when reading a counter

  def scan(from: Bytes, to: Bytes): Future[Spool[(Bytes, Value)]]
  def scanByteValues(from: Bytes, to: Bytes): Future[Spool[(Bytes, Bytes)]] // skips counters
  def scanCounterValues(from: Bytes, to: Bytes): Future[Spool[(Bytes, Long)]] // skips bytes
}

Arguably, we could use Either[Bytes, Long] but would make pattern matching less explicit (case Right(counter) vs. case CounterValue(counter))

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant