Closed leonardb closed 4 years ago
Not having support for atoms/lists and maps in erlfdb makes the tuple layer more complex to use.
This PR adds support for transparent encoding/decoding from/to native erlang atom, list and map types.
atom
list
map
My specific use case is for storing erlang records in fdb and have the native records as results when selected.
I'd prefer not to hammer term_to_binary and binary_to_term for every single operation in my app.
I used the documented "User type codes" (Typecodes: 0x40 - 0x4f) to specify these.
Honestly not sure if this should be included here.
Maybe there is a better way to design this?
Not having support for atoms/lists and maps in erlfdb makes the tuple layer more complex to use.
This PR adds support for transparent encoding/decoding from/to native erlang
atom
,list
andmap
types.My specific use case is for storing erlang records in fdb and have the native records as results when selected.
I'd prefer not to hammer term_to_binary and binary_to_term for every single operation in my app.
I used the documented "User type codes" (Typecodes: 0x40 - 0x4f) to specify these.
Honestly not sure if this should be included here.
Maybe there is a better way to design this?