[The documentation for Depo is at HexDocs.](https://hexdocs.pm/depo)
## Goals
Depo is meant to provide lightweight storage and querying
capabilities in Elixir by providing a minimal and polished API
that builds on the unique advantages of SQLite, inspired in spirit
by the SQLite Tcl API ([specification](https://www.sqlite.org/tclsqlite.html); [implementation](https://github.com/mackyle/sqlite/blob/master/src/tclsqlite.c).
The lightweight and dynamic nature of SQLite makes it well-suited
as an option for adding simple transactional disk-backed
storage and query capabilities to small Elixir processes.
SQLite uses very little memory, and enables you to quickly
create, open, or update many databases programmatically.
Elixir programmers know the advantages of many small things
working together, and SQLite does too.
[Dets](http://erlang.org/doc/man/dets.html), the native Erlang
disk-backed option, has a file size limit of 2GB, while SQLite
files have a 140TB limit.
[Mnesia](http://erlang.org/doc/man/mnesia.html) adds transactional
guarantees to Dets, but introduces lots of complexity as well.
SQLite is a great option when you want fast, transactional
flexible disk-backed storage with zero configuration.
Depo uses Erlang NIFs (Native Implemented Functions) provided
by [Esqlite,](https://github.com/mmzeeman/esqlite) which you can
also use directly for a more low-level API.
An alternative library for using SQLite in Elixir is
[Sqlitex.](https://github.com/mmmries/sqlitex)
## Installation
Depo can be installed by adding `depo` to your list of
dependencies in `mix.exs`:
```elixir
def deps do
[{:depo, "~> 1.2.1"}]
end
```
## Utilizing the Dynamic and Lightweight Nature of SQLite
From the [guide on appropriate uses of SQLite](https://sqlite.org/whentouse.html),
the authors say "SQLite does not compete with client/server
databases. SQLite competes with [fopen()](http://man.he.net/man3/fopen)."
SQLite is commonly misunderstood as being an inferior client-server
database (e.g. "a non-production-ready Postgres"), while it really
just has totally different goals and design trade-offs.
Those goals were shaped by SQLite's origin as an extension to the
[Tcl programming language][tcl], which shares many properties with Elixir.
Tcl is dynamic, functional, extensible, and features persistent
immutable collections and channels, much like Elixir.
The author of SQLite, Dr. Richard Hipp, has [written a paper][hipp1] and
[given a presentation][hipp2] about the role Tcl played in its development.
SQLite doesn't enforce data types on columns, which can be a
useful property to take advantage of in the context of a dynamic
language like Elixir.
You can handle defining data types and encoding/decoding in your
application and SQLite will just get out of your way.
SQLite has [comprehensive documentation about its dynamic data typing.][dyn]
SQLite uses very little memory, so it makes it feasible to
use many smaller databases simultaneously instead of just
using a single huge one.
This helps encourage a more modular database design.
## Contributing
Thank you for your interest!
Please feel free to make a new issue for any questions,
bugs, or feature ideas.
Pull requests are welcome, but please make an issue first
for large changes so we can discuss the best design before
you spend your time writing all the code and tests first.
## Pre-Release Checklist
1. `mix test`
1. change version number in `mix.exs` to vX.Y.Z in accordance with [semantic versioning](http://semver.org/)
1. `git add -A .`
1. `git commit -m "description of changes"`
1. `git tag vX.Y.Z`
1. `git push`
1. `git push origin vX.Y.Z`
1. `mix hex.publish`
[tcl]: http://www.tcl.tk/about/language.html
[dyn]: https://sqlite.org/datatype3.html
[hipp1]: https://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.pdf
[hipp2]: http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2009/proceedings/sqlitetcl/tcl2009-sqlite.pdf
