Fix typos

docs/features/streaming-caches.md

@@ -44,4 +44,4 @@ query = Cachex.Query.create(filter, :value)
 |> Enum.sum
 ```
 
-Couple of things to mention here; first of all, you can use any of the `entry()` field names in your matches, and they'll be substituted out automatically. In this case we use `:value` in our filter, which would compile down to `:"$4"` instead. You might also have noticed that we can jump directly to `Enum.sum/1` here. The second (optional) argument to `create/2` controls the format of the stream elements, in this case just streaming the `:value` field of the entry. If the second argument is not provdided, it'll stream entry records (just like the first example). It should be noted that `Cachex.Query.create/2` will automatically bind a filter clause to filter out expired documents. If you wish to run a query on the entire dataset, you can use `Cachex.Query.raw/2` instead.
+Couple of things to mention here; first of all, you can use any of the `entry()` field names in your matches, and they'll be substituted out automatically. In this case we use `:value` in our filter, which would compile down to `:"$4"` instead. You might also have noticed that we can jump directly to `Enum.sum/1` here. The second (optional) argument to `create/2` controls the format of the stream elements, in this case just streaming the `:value` field of the entry. If the second argument is not provided, it'll stream entry records (just like the first example). It should be noted that `Cachex.Query.create/2` will automatically bind a filter clause to filter out expired documents. If you wish to run a query on the entire dataset, you can use `Cachex.Query.raw/2` instead.

docs/migrations/migrating-to-v2.md

@@ -12,7 +12,7 @@ In order to migrate away from this, you should now implement a backing datastore
 
 The decision to remove the remote interface does not come lightly; I have spent many weeks trying to conjure something which satisfies the desire of both speed and distribution and the sad truth is that it's quite simply hard to do well. The consistency issues which plague the land of distributed data are just not possible to handle whilst keeping Cachex as fast as it is (and at the end of the day, a cache is supposed to be fast). The final tipping point was the concept of building LRU style caches in a remote context; it's simply not possible to guarantee the consistency of your data without a huge performance hit (we're talking upwards of 1000x slower) due to Cachex operating in the realm of a microsecond.
 
-Do not despair though; if you were totally set on using a native Elixir/Erlang datastore witout having to have something separate such as Redis, I'm planning on writing a separate library which is dedicated more to handling the distributed nature as opposed to the feature set that Cachex offers. At the end of the day, I see caching as a different use case to remote data replication - I believe remote Cachex was closer to a distributed state table, rather than a local mirror of data.
+Do not despair though; if you were totally set on using a native Elixir/Erlang datastore without having to have something separate such as Redis, I'm planning on writing a separate library which is dedicated more to handling the distributed nature as opposed to the feature set that Cachex offers. At the end of the day, I see caching as a different use case to remote data replication - I believe remote Cachex was closer to a distributed state table, rather than a local mirror of data.
 
 In addition, you can obviously keep on using Cachex `v1.x` as long as you need - it's still on Hex.pm and has a tag on the repo. I can't promise anything new will be added to that codebase, but for what it's worth I do intend to answer any issues reporting bugs on that branch, so file issues as you see fit - just make sure to flag that you're talking about `v1.x`.
 
@@ -97,7 +97,7 @@ There are a few minor tweaks to the options when starting a cache:
 
 ## Transactions
 
-As of Cachex v2.x, Mnesia has been removed in favour of direct ETS interation. As a result of this, there are several changes in the way transactions work.
+As of Cachex v2.x, Mnesia has been removed in favour of direct ETS integration. As a result of this, there are several changes in the way transactions work.
 
 The first change is down to optimizations of key locking, and requires that you now pass a list of keys to lock as your second parameter to a `transaction/3` call. This is part of the new locking implementation which allows for several optimizations by being explicit with your locks. This optimization provides roughly a 5x speedup, so it's much more efficient than previously. This is pretty easy to adopt:
 

lib/cachex/actions/touch.ex

@@ -5,7 +5,7 @@ defmodule Cachex.Actions.Touch do
   # Touching an entry is the act of resetting the touch time to the current
   # time, without affecting the expiration set against the record. As such
   # it's incredibly useful for implementing least-recently used caching
-  # systems without breaking expiration based constracts.
+  # systems without breaking expiration based contracts.
   alias Cachex.Actions
   alias Cachex.Services.Locksmith
   alias Actions.Ttl

lib/cachex/disk.ex

@@ -1,6 +1,6 @@
 defmodule Cachex.Disk do
   @moduledoc """
-  Module dedicated to basic filesystem iteractions.
+  Module dedicated to basic filesystem interactions.
 
   This module contains the required interactions with a filesystem for serializing
   terms directly to a given file path. This is mainly used by the backup/restore

lib/cachex/spec.ex

@@ -144,7 +144,7 @@ defmodule Cachex.Spec do
   @doc """
   Creates an entry record from the provided values.
 
-  An entry record reprents a single entry in a cache table.
+  An entry record represents a single entry in a cache table.
 
   Each entry has a key/value, along with a touch time and ttl. These records should never
   be used outside of the Cachex codebase other than when debugging, as they can change

lib/cachex/stats.ex

@@ -19,7 +19,7 @@ defmodule Cachex.Stats do
   # add our aliases
   alias Cachex.Options
 
-  # update incrementers
+  # update increments
   @update_calls [
     :expire,
     :expire_at,

test/cachex/actions/put_many_test.exs

@@ -3,7 +3,7 @@ defmodule Cachex.Actions.PutManyTest do
 
   # This test verifies the addition of many new entries to a cache. It will
   # ensure that values can be added and can be expired as necessary. These
-  # test cases operate in the same way as the `set()` tests, jsut using the
+  # test cases operate in the same way as the `set()` tests, just using the
   # batch insertion method for a cache instead of the default insert.
   test "adding many new values to the cache" do
     # create a forwarding hook

test/cachex/actions/stats_test.exs

@@ -33,7 +33,7 @@ defmodule Cachex.Actions.StatsTest do
 
   # This test just verifies that we receive an error trying to retrieve stats
   # when they have already been disabled.
-  test "retrieving stats from a diabled cache" do
+  test "retrieving stats from a disabled cache" do
     # create a test cache
     cache = Helper.create_cache(stats: false)
 

test/cachex/actions/transaction_test.exs

@@ -83,7 +83,7 @@ defmodule Cachex.Actions.TransactionTest do
   # a cache cluster, instead of just the local node. We're not concerned
   # about the actual behaviour here, only the routing of the action.
   @tag distributed: true
-  test "transcations inside a cache cluster" do
+  test "transactions inside a cache cluster" do
     # create a new cache cluster for cleaning
     {cache, _nodes} = Helper.create_cache_cluster(2)
 

test/cachex/services/janitor_test.exs

@@ -45,7 +45,7 @@ defmodule Cachex.Services.JanitorTest do
   # The Janitor process can run on a schedule too, to automatically purge records.
   # This test should verify a Janitor running on a schedule, as well as make sure
   # that the Janitor sends a notification to hooks whenever the process removes
-  # some keys, as Janitor actions should be subscribable. This test will als
+  # some keys, as Janitor actions should be subscribable. This test will also
   # verify that the metadata of the last run is updated alongside the changes.
   test "purging records on a schedule" do
     # create our forwarding hook