ironcorelabs/davenport

A principled CouchBase library for Scala

davenport's Issues

Add document write-locking to CouchBase

I don't think we should lock documents, but we will likely need this if we end up doing transactions in the future. See "Reading and Locking" here:

http://developer.couchbase.com/documentation/server/4.0/sdks/java-2.2/documents-retrieving.html

Should be easy to implement in MemInterpreter.

Encode `Key`s in strings to safely present non-printable characters

Unless you have a guarantee about Key containing only printable characters, it might be worth devising an encoding for non-printable Keys in strings like a
https://github.com/coltfred/davenport/blob/cleanupDBDocument/src/main/scala/com/ironcorelabs/davenport/DB.scala#L154

Auto-turn on indexing (and note couchbase 4 dependency)

Add .queryEnabled(true) to the environment builder. That will require CouchBase 4, but as it is now officially released and we have other dependencies on it (key scanning) we should document that requirement anyway.

Bucket passwords should not be passed around in plain text

I shudder when I see plain text passwords passed around and stored in config files or in source code. It seems like we ought to be able to help a user out with that being as we are a crypto company and all.

The approach would be to create a separate tool or an API or both for someone to input a password and get back something encrypted. Then when opening a bucket, maybe we have a plain text password option and maybe we have an encrypted password option. We'll decrypt it, but meanwhile wherever it was stored was at least somewhat protected.

Our protection can't be fantastic, but I believe it would be better than nothing. I would argue for generating a symmetric key using PBKDF1 using inputs that are specific to the calling application. Or better yet, the app provides some identifier (preferably app name and some random number that they store) and that can be used to generate a key that unlocks the password. So at least the app key is in code and the password is in the config file. Pretty low level of security, but still better than plain text passwords floating around.

Add bucket management options

Create/delete buckets on demand and then test multi-bucket handling in both Couch and Mem. Some Couch details: http://docs.couchbase.com/sdk-api/couchbase-java-client-2.2.0/com/couchbase/client/java/event/consumers/BucketConsumer.html

Add index and index query capabilities

Simpler than arbitrary N1QL is the index capabilities of CouchBase 4. In particular, I mean the "Global Secondary Index" -- http://developer.couchbase.com/documentation/server/4.0/indexes/indexing-overview.html. See also: http://developer.couchbase.com/documentation/server/4.0/sdks/java-2.2/querying-n1ql.html

The thought here would be that you register a field to be indexed and then make lookups based on the indexed field. This should be more straight forward and simplified and relatively easy to model in MemInterpreter.

Rename interpreter

The fact that davenport is implemented using Scala free monads seems like a detail that could be hidden. The name "interpreter" doesn't seem to help much with comprehending the package and how to use it.

Add an ADT for error cases

Currently we package up errors into disjunctions that return any arbitrary Exception. The library would benefit more from a finite list of defined error conditions.

Daily snapshots are published incorrectly

Right now daily snapshots require you to specify -SNAPSHOT-SNAPSHOT which is ugly.

While we're at it, should add getting started directions for how to use snapshots.

Rename HashVer/hashVer to CommitVer/commitVer

I think the name "hashVer" may lead users to think they are responsible for computing and submitting this value. (Actually, reading the documentation from couchbase, I'm not even sure it is actually a hash).

Add N1QL access to interpreter capabilities

CouchBase 4 adds a sql-like query language that can be used to fetch lists of apps based on fields inside json docs. This might be very hard to represent for the MemInterpreter, which would be a requirement, but we could perhaps implement specific, strict subsets of N1QL . This would not need to support the SQL syntax, just stronger query capabilities.

Add release process to CONTRIBUTING.md doc

The contributing guide should say what you need installed...

When attempting to run sbt previewSite I received an error about needing jekyll.

java.io.IOException: Cannot run program "jekyll" (in directory "/home/cfrederickson/src/github/coltfred/davenport/src/jekyll"): error=2, No such file or directory

It should mention you need Jekyll (and what version of Jekyll you need).

CouchConnectionSpec should verify consistency with MemConnection.

Currently we have 2 separate test suites for MemConnection and CouchConnection. We should be able to abstract over these and potentially verify consistency between the two.

Add more error cases to the new errors ADT

In particular, we have these known general exceptions:

• - The operation takes longer than the specified timeout: {@link TimeoutException} wrapped in a {@link RuntimeException}
• - The producer outpaces the SDK: {@link BackpressureException}
• - The operation had to be cancelled while on the wire or the retry strategy cancelled it instead of
• retrying: {@link RequestCancelledException}
• - The durability constraint could not be fulfilled because of a temporary or persistent problem:
• {@link DurabilityException}.
• - A CAS value was set on the {@link Document} and it did not match with the server: {@link CASMismatchException}
• - The server is currently not able to process the request, retrying may help: {@link TemporaryFailureException}
• - The server is out of memory: {@link CouchbaseOutOfMemoryException}
• - Unexpected errors are caught and contained in a generic {@link CouchbaseException}.

I think we can put these into three buckets: CAS error, server error and connection error as a way to simplify further.