-
Notifications
You must be signed in to change notification settings - Fork 0
Details
- transactions
- locks
- ordinary mnesia-calls in a transaction context and as dirty_operations
(read, write, create_table, delete_table, info, table-iterations (as last, first, prev, next and all_keys) and more). - views, by looking at them as dirty operations
- record to json, json to record-conversion – look at the bottom of this doc.
- mnesia:select,
mnesia:index_read and
mnesia:match_object if you catch a
specific call to them in cdb_tab and sending the query to a CouchDB view –
ad_hoc. - ‘complex datatypes’ as port, pid, funs, >32bit integers, floats and so on
needs some modification of the code in order to work due to impedance mismatch
(they need to be encoded as a base64-string or similar, or tagged up like the
tuple-type).
- the same stuff that isn’t working with Mnesiaex
- dynamic queries like mnesia:select or mnesia:match_object without
changing cdb_tab - revision control (are ignored due to the pessimistic concurrency control of
mnesia)
- Proper distribution. Right now the location of the server isn’t stored in
mnesia’s schema but if the location of the server is configured (i.e not
every node is pointing to the same server ^^) it will distribute fine - The revision cache aren’t cleared so it can grow out of control (really easy
to do but is there need for it?). - Index/view creation from mnesia. The views must be added manually at this
point. Could add a view when creating an index from mnesia. - Replication via mnesia. The replication hasn’t been touched at all and there’s
no code for it in cdberl atm
- cdberl communicates with CouchDB via HTTP by using the erlang_couchdb module
- for now cdb_com assumes that there are one, and only one, design document in
a table. Otherwise the functionality of mnesia:first/last is broken but
with some modification of cdb_com:first and cdb_com:last that can be
ignored. - the doc._id is for now a base64 representation of the record key but that can
be changed - In a mnesia transaction, writing to the backend is made after a commit
message has been written to the transaction log. This implies that if
CouchDB (or DETS) goes down in the middle of doing some writes, mnesia still
regards the transaction as a successful one. - for more information check inline documentation or send me a message!
- to add a table we sometimes need to add cases to the following functions:
- cdb_doc:rec_to_doc/2 1
cdb_doc:doc_to_rec/2 1
cdb_util:default_vals/1 2
cdb_util:encode_key/2 3
cdb_util:decode_key/2 3
Hard nut to crack due to impedance mismatch: e.g no objects in Erlang and no tuples, atoms or large integers in JSON. Tuples and large integers was the hardest problem and has no pretty solution. I’ve left the integer part so it just works with some of my tables but clearly it is not ready.
| Erlang term | JSON | |
|---|---|---|
| List, “123” | Array, [49,50,51] | |
| Tuple, {1,2,3} | JSON object, {"tuple": [1,2,3]} | |
| Atom, foo | JSON string, “foo” | |
| Float | N/A – TODO | |
| Fun | N/A | |
| N/A | JSON object | |
| Big Integer > ~2^53 | Float, truncated – TODO | |
| Medium Integer 2^32< X < 2~53 | Float – TODO | |
| Small Integer < 2^32 | Integer – TODO |
Change the proper row in cdberl.app or just change it by calling
cdb_srv:set_server(Tablename, {server, "http://it.uu.se", 5984})
or
cdb_srv:set_server(default, {server, "http://it.uu.se", 5984}).
(The changes aren’t permanent but should be.)
1 only needs to be implemented if there are special “terms” that collide with
json types and javascript inbuilt types. I.e
integers > 32bit will be converted (by CouchDB) to floats upon insertion
in database and converted back (by cdberl) to integer when reading the
value. That leads to the implication that integers with more than ~16
digits will be converted to floats and truncated when converting back to
integer. It also leads to the fact that floats cannot be stored in
database unless special implementation in cdb_doc:doc_to_rec and
rec_to_doc is done.
2 If you don’t want to use mnesia you can access couchdb with cdberl
directly but then you need to specify the default-values for
the record in cdb_util:default_vals/1, otherwise you will get an
exception.
3 If you aren’t happy that a doc.id is a base64 representaion of your
record’s key then you can use encode_key and decodekey to implement
your own encoder/decoder