ripcordsoftware / avancedb Goto Github PK

AvanceDB should support JavaScript Map/Reduce to the same level as CouchDB 1.6. Reducers should be limited to _stats, _count and _sum.

If a string contains characters significant to JSON then the client will fail to parse responses correctly

The Document/ScriptObject JSON response streamer renders the JSON to a memory buffer before dispatching to the client. The streamer should use a fixed buffer and emit serialized blocks into the buffer for writing to the client. This will substantially reduce the memory overhead for large responses.

Also: remove the delete _revisions lines from the JS test scripts to confirm the change.

Protocol Buffers is a much more compact and low CPU overhead protocol compared to JSON. Clients could detect the presence of AvanceDB via a signature sniff or a no side effect PUT/POST and cache the support level of the remote. Alternately passing their willingness to use PB to the server via the Accept header would enable PB responses.

To get max value from this client implementers would need to support it. Should be easy to modify Cradle or Nano via a fork and PR.

See issue RipcordSoftware/libscriptobject#15

Safari renders a blank page when it receives a 304 response. The client and server headers look ok. This appears to only be an issue on OSX and is limited to Safari.

If a client uses %2f instead of / in the request this is not translated into the correct path.

See RipcordSoftware/libscriptobject#9

The test suite should be useful for limited functional testing, soak testing, performance testing, concurrency testing and memory leak testing.

Add caching, stale and result delta support.

Continuous repl to AvanceDB from CouchDB seems to provoke CouchDB into doing very weird stuff. Single-shot repl is 100% so continuous must be making calls to AvanceDB and getting responses it can't handle.

See RipcordSoftware/libscriptobject#11

AvanceDB places no significance to the _deleted field in documents. To CouchDB these are deleted and we should follow this behaviour. The oddness comes from documents that arrive via PUT/POST with the field set, not for a DELETE REST request.

The gason JSON parser doesn't handle the JavaScript Number.MIN_VALUE or Number.MAX_VALUE constants when assigned to a field in a document.

Both these values result in invalid values, in the case of MAX_VALUE the field equates to infinity which breaks outbound JSON serialization.

Without caching paging is slow when the database is very large.

It is possible for map/reduce functions to modify the JS global object. This state will persist between calls and could be exploited.

Using JS_DeepFreezeObject on the global prevents new code (map/reduce) being run in the thread context since it prevents any modifications being made to the runtime.

Ideally the map function should not be able to modify the global object or alternately the global object should be reset at the end of the map/reduce pass.

The repo is here: https://github.com/google/snappy/tree/master

Apparently some people use Swift and would like tests??!

If a document id contains non-ascii chars the regex dispatcher will fail to match resulting in a 404. CouchDB can handle UTF-8 chars in ids.

Need to understand behaviour when emitted as map keys and when sorting in all_docs.

Test should include:

• document add
• document update
• document remove
• bulk add/update

Sequence number correctness is critical for cache behaviour.

On systems with hyperactive selinux present (RHEL/Fedora/etc) port 5994 causes a security flip out. The example case is replicating from a locally installed CouchDB instance to AvanceDB. Without a security file update the only option is to make selinux less agressive, this is a system wide change and may not be acceptable.

See RipcordSoftware/libhttpserver#6

The Put/DeleteDatabase implementation does not match the CDB spec for error handling. This must be implemented.

When a bulk docs request is made with new_edits set to false couchdb responds with []. It is not necessary to respond with a normal bulk docs response since the revs are already known.

Avance should match the couchdb behaviour.

Possibly based on: https://github.com/google/leveldb

Specifically:

• re-use already known values for date/time
• user agent string char replace
• address type check for local/remote
• potential overflow under high load

Probably need a config file entry for this

Boost.Python should be the starting point for development

Currently characters are handled as 8bit. No encoding is performed. This is likely to be an issue for JSON encoded unicode chars - for example: /ubaad.