[erlang-questions] Implementing an erlang server to host organizational data

[Sean Cribbs]

On Tue, Dec 1, 2015 at 4:33 AM, Khitai Pang <khitai.pang@REDACTED> wrote:

>
> How to store the data on disk? Mnesia?  How to organize the data? Does
> erlang has some OTP-fu to handle tree data?  Does erlang has a way to do
> mutex?  How do erlang server and clients talk to do data syncing?  Can the
> syncing be done by communicating with raw Erlang terms?
>
>
There are many ways to store on-disk (although I like Kevin's LDAP idea
best). Mnesia is neat but might not be what you want if your goal is to
sync with clients. There are a number of key-value storage engines that
could work, or you could just the entire data structure write to a file
occasionally.

For the data you are modeling, records or maps seems appropriate (although,
I'm wondering how a branch of the org tree doesn't have a manager where the
branch's children are her direct reports). If it were records, I might do
it like so:

-record(branch, {children=[] :: #employee{} | #branch{}}).
-record(employee, {name :: string(), title :: string()}).

>From that it's straightforward to do depth-first traversal of the tree:

traverse(#branch{children=C}, Fun) ->
    lists:foreach(fun(R) -> traverse(R, Fun) end, C);
traverse(#employee{}=E, Fun) ->
    Fun(E).

"Mutex" is something that doesn't really exist in Erlang because there's no
direct concept of shared memory. Instead, I'd send all mutations (and
possibly reads) of a shared structure through a single process whose only
purpose is to serialize access to the state of the structure. This is a
very common pattern. If you can tolerate reads being unserialized ("dirty"
or "stale"), put the state in an ets table that has public reads. This
works well in high-read, low-update scenarios.

Serialized Erlang terms are great, but not incredibly interoperable. I'd go
with a more commonly used format. For text, XML or JSON, for binary or more
compact representations, I'd use msgpack, Protocol Buffers, or ASN.1.

"Syncing" is a whole other topic that requires a primer on distributed
systems that can't fit in this email. I suggest reading
http://book.mixu.net/distsys/ when you have the time. Even implementing a
simple best-effort delivery is full of deep potholes, not to mention
handling concurrent updates.

Sorry to ask so many questions, some may be off-topic in an mailing list
> for Erlang the programming language.  I really need some guidance before
> start working on it.  And I want to know in what way erlangers' would tend
> to implement this.
>
>
> Thanks
> Khitai
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151201/3f9ff2b9/attachment.htm>