This is a work in progress. There's also an article about sumo_db. This articles might be a little outdated by now, but can still provide some basic information on how to get started.
sumo_db aims to ease db access for erlang applications. It offers a very simple persistance layer capable of interacting with different db's, while offering a consistent api to your code.
For questions or general comments regarding the use of this library, please use our public hipchat room.
If you find any bugs or have a problem while using this library, please open an issue in this repo (or a pull request :)).
And you can check all of our open-source projects at inaka.github.io
-
sumo_db gives you a standard way to define your db schema, regardless of the db implementation (mongo, mysql, redis, elasticsearch, etc.).
-
Your entities encapsulate behavior in code (i.e. functions in a module) and state in a
sumo:doc()implementation. -
sumois the main module. It translates to and from sumo internal records into your own state. -
Each repo is managed by a worker pool of processes, each one using a module that implements sumo_repo and calls the actual db driver (e.g: sumo_repo_mysql).
-
Some native domain events are supported, that are dispatched through a
gen_event:notify/2automatically when an entity is created, updated, deleted. Also when a schema is created and when all entities of a given type are deleted. Events are described in this article. -
Full conditional logic support when using
find_by/2anddelete_by/2function. You can find more information about the syntax of this conditional logic operators here. -
Support for sorting (
ascordesc) based on multiple fields unsingfind_by/5andfind_all/4functions. For example this[{age, desc}, {name, asc}]]will sort descendently byageand ascendently byname.
These three concepts have a specific meaning in the context of sumo_db.
-
Backend: holds the connection to a single instance of a database, which can be MySql, MongoDB, ElasticSearch or any other that's implemented.
-
Store: implements the specific operations that modify the contents of the backend and retrieves the information it holds.
-
Repository: the application that uses
sumo_dbshould implement one repository for each entity that's defined in it. The repository is the module that bridges the model and the store.
TO implement an adapter, you must implement two behaviors: sumo_backend and
sumo_store.
See: examples/blog for a full example. To run it, while being in the top level directory:
make all blog
$ rebar3 dialyzer
$ rebar3 ct
All notable changes to this project will be documented in the CHANGELOG.md.
We want to thank all of our contributors for their hard work :muscle:.