GitXplorerGitXplorer
k

lomongo

public
2 stars
0 forks
0 issues

Commits

List of commits on branch master.
Unverified
0d862decd0d2a47717eaa67352e7184da43ad35f

Upgrade to Scala 2.8.1 and replace SynchronousQueue with SyncVar

kkim committed 14 years ago
Unverified
62f7e4c3e3d7265045dde537ceb274010d3d54fd

Make I/O asynchronous & allow to timeout on reply promise

kkim committed 14 years ago
Unverified
4daf49378b1ff6d1ff5447845fa68af56465960d

Return the correct queue for reply promise

kkim committed 14 years ago
Unverified
86eb489b3f0f8204294477a11162449e5d66c661

Note todo, remove debug stuff

kkim committed 14 years ago
Unverified
36ba5aeeb7039cbe663050cfe1f96b56dfdabc16

Housekeeping

kkim committed 14 years ago
Unverified
da7abc3849f0c4214d6b4e1555204e74306c0359

Make foreach reentrant.

kkim committed 14 years ago

README

The README file for this repository.

Lomongo

Lomongo (ISO-639-3: lol) is a language spoken by several of the mongo peoples in the Democratic Republic of Congo

Lomongo is a driver for MongoDB written in Scala and trying to be really functional (not through using funny characters, though). It uses Netty for IO.

Installation and Usage

Install using sbt:

sbt update
sbt install

For an example of how to use the driver, see main.scala.

Motivation

Existing drivers for MongoDB are quite clumsy to work with from Scala, mainly because they try to create a Scala interface on top of the Java driver, which is not only very OO, but also very weakly typed. Thus, those drivers make heavy use of implicit conversions, which predictably goes horribly wrong in non-trivial use-cases. However, trying to create a functional, strongly typed Scala driver requires one to re-implement the protocol and serialization layers, hence this project may or may not reach production quality (and will be maintained actively enough to stay there). Thus, patches and contributions are highly welcome.

Todo

  • some of the administrative commands have no wrappers yet
  • map/reduce is not implemented at all
  • BSON encoding/decoding should be decoupled from Netty Channels
    • compare performance / GC characteristics of:
      • Stream (including forcing / wrapping in Channel)
      • Array of nested 'word' Arrays wrapped in Channel
      • NIO ByteBuffer (including allocating more capacity)
  • the interface follows the native API very closely -- a 'funny characters' API, possibly exposing 'Collection'-semantics, could be nice

Contributing

Send questions, bugs or patches to kim.altintop@gmail.com

License

BSD-like, see LICENSE