Awesome

Mnemonix

A unified interface to key/value stores.

Synopsis

Mnemonix aims to help you:

• Get running with key/values stores with minimal ceremony
• Experiment with different key/value store backends for your application
• Allow end-users of your library liberty to choose their preferred backend

It encodes the behaviour, lifecycle, and feature set of a key/value store behind a common GenServer interface, normalizes different store APIs to conform to that interface, polyfills stores lacking features, and exposes access to them through a familiar Map API.

Learn more about starting a store and manipulating it with the Mnemonix API in the documentation.

Pronunciation: /nɛˈmɑːnɪks/ – noo-MAHN-icks

Mnemonic systems are techniques or strategies consciously used to improve memory. They help use information already stored in long-term memory to make memorization an easier task.

— Mnemonics, Wikipedia

Status

:thumbsup:	Continuous Integration	Test Coverage
Master
Development

Features

Obviously, Mnemonix gives you Map-style functions to manipulate various key/value stores. However, Mnemonix also offers extra features beyond simple Map functions. Stores that don't natively support these features have the capability added through an Elixir polyfill, guaranteeing you can use and switch stores without worrying about what features they support under the hood.

Available features are:

• Mnemonix.Features.Map - The key/value manipulation you know and love
• Mnemonix.Features.Bump - Increment/decrement integer values
• Mnemonix.Features.Expiry - Set entries to remove themselves from the store with a ttl
• Mnemonix.Features.Enumerable - Iterate over all key/value pairs in supported stores
• Mnemonix.Features.Supervision - Handles start_link for custom stores so they fit in with built-in tools

Installation

• Add Mnemonix to your project's dependencies in its mix.exs:

  def deps do
    [{:mnemonix, "~> 0.9.0"}]
  end
  

• Ensure Mnemonix is started before your application:

  def application do
    [applications: [:mnemonix]]
  end
  

Contributing

Pull requests are welcome and greatly appreciated!

Please submit them against the development branch rather than master––this allows useful changes to be finessed before release. The GitHub UI should do this by default.

Here are some useful commands if you've just forked the project and want to contribute:

• mix deps.get - Get development dependencies
• mix test - Run the test suite
• mix credo - Run static code analysis on Elixir source
• mix dialyzer - Run static code analysis on compiled BEAM bytecode
• mix docs - Generate documentation files
• mix clean - If any of the above stop behaving as expected

Testing

Setup

Some parts of the test suite are contingent upon configration of out-of-memory systems. Detection of these systems can be configured through environment variables. If they can't be detected, the parts of the suite that rely on them will be skipped.

• Mnesia
  • FILESYSTEM_TEST_DIR: The location of a filesystem Elixir can read from and write to.
    • Default: System.tmp_dir/0
• Redis
  • REDIS_TEST_HOST: The hostname of a redis server.
    • Default: localhost
  • REDIS_TEST_PORT: The port on the host redis is accessible at.
    • Default: 6379
• Memcached
  • MEMCACHED_TEST_HOST: The hostname of a memcached instance.
    • Default: localhost
  • MEMCACHED_TEST_PORT: The port on the host memcached is accessible at.
    • Default: 11211
• ElasticSearch
  • ELASTIC_SEARCH_TEST_HOST: The hostname of an ElasticSearch instance.
    • Default: localhost
  • ELASTIC_SEARCH_TEST_PORT: The port on the host ElasticSearch is accessible at.
    • Default: 9200

Doctests

By default, the test suite omits doctests. This is because, by nature of the library, for full working examples in documentation to act as integration tests, some external state must be stored in an out-of-memory system. Normal tests have the opportunity to correctly configure these systems; doctests do not.

If you wish to run these, use the environment variable DOCTESTS=true. For them to pass, your system must be configured using the defaults in the setup steps specified above.

The CI server fulfills these requirements, so if you can't, you can always configure your fork to use travis too, to get the same build environment we use to vet all pull requests.

Notes

• Not to be confused with the mnemonicode library, Mnemonex.