riak-ruby-ledger 0.0.5 → 0.0.6

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    YmFiZWE5ODMwODQwODRiYzI3YjBjM2Y5ZDAwMmM0NzI4Y2ZhZDZlNA==
+    NTJhNWMzN2E2NTNiYTQ2MzAzMDM5ODI2NDUwYTZlMjNjZDc1NjE3ZA==
   data.tar.gz: !binary |-
-    ZDNhNDI3MzA5NWZjY2U3NGRhYjAxNGMzYzVhOTEwMGUzZTZjYTA5OQ==
+    NTE5YjllZjJlMWJjMGM4NmZkNzRmNjNjNzEyNmJiY2EyNzg4YjU2OA==
 SHA512:
   metadata.gz: !binary |-
-    YjI5MzU1MzVhYzZhZDY4Y2UwMzJiNGJkMDc3YjdjY2JmNmU5MTM4MzM4ZjQ3
-    OTRjYjI5Mzg5NTI4ZGIxY2M5MjUwNmY3YWVlZmRhNDI2OWViZmIzZWZhYjQw
-    ODE1NTFhYWQyM2YwZDU0OGVhYzQyYjUxMTgxZjRiMTcwZmNmNGE=
+    MDc5YTA3MGE5MDBhZTc1YTc5Yzc0Y2FjNzQ5YjhmYjgwN2IyZGI0ZGNhYjI0
+    YzI3ZjhhYzZkMTIyOGE4YjU5N2NiNGQ1Njc0YzVhZjI4NzA3ZDI2ZmJiZjA2
+    YTIzNTE4MWQ5YzlkYmMwZjhiZjBmNzcyZjRjZDVjZTk1Zjk5NzA=
   data.tar.gz: !binary |-
-    ZjRmNjQ3NmJhNzlmNTBjMWNmMGM2ZWFhNWRhNjJiMGQxMzFhNmIzYzI1M2Fk
-    MGM2YzU1YWEwNzRmYzYxYTVmMzdhYzc2NTFhNzdiMjZhNDNiYTliMjQwNjFj
-    MThjZTAxMzc2MDFhMTk5ODdiZjM5NWY2ZDJiYzcyZjg4NDc1MTM=
+    ZTk4NWM5OWZjYWQ2YjI0NDJmMjA4ODcyZGQ1MjY1YzVjNzFhYjZkNzEwYjQy
+    OWY4OWRiZWZlNzk1ODkzNjNmNTVkMDFlZGViYjFiM2M4YjUzZTk0OTNkMmMw
+    NmU5NjhlYmUzNGM0MTIxZTg5N2NlMDI1YjJmOWIzYmIyOWVlYTA=

data/README.md

@@ -1,5 +1,7 @@
 # Riak-Ruby-Ledger
 
+[![Gem Version](https://badge.fury.io/rb/riak-ruby-ledger.png)](http://badge.fury.io/rb/riak-ruby-ledger)
+
 An alternative to Riak Counters with idempotent writes within a client defined window.
 
 # Summary
@@ -116,6 +118,12 @@ Thread.current["name"] = "ACTOR1"
 # Create a Riak::Client instance
 client = Riak::Client.new pb_port: 8087
 
+# Get the Riak::Bucket instance
+bucket = client["ledgers"]
+
+# Set allow_mult to true
+bucket.allow_mult = true unless bucket.allow_mult
+
 # Default option values
 options = {
 	:actor => Thread.current["name"], # Actor ID, one per thread or serialized writer
@@ -125,7 +133,7 @@ options = {
 
 # Create the ledger object
 #                         Riak::Bucket        Key        Hash
-ledger = Riak::Ledger.new(client["ledgers"], "player_1", options)
+ledger = Riak::Ledger.new(bucket, "player_1", options)
 ```
 
 ### Credit and debit

data/docs/release_notes.md

@@ -5,24 +5,24 @@
 In version 0.0.4 of this gem, counter drift is still a possibility. Take the following scenario into consideration:
 
 1. Actor 1 and Actor 2 both are somehow trying to write the same transaction id, possibly because the process writing the transaction took too long, and your application erroneously had a policy of retrying the same transaction before the first actor finished.
-    a. If the Actor 1 is successful in writing the transaction before Actor 2 begins, Actor 2 will see that the transaction id already exists, and will return successful before attempting to write.
-    b. Similarly, if Actor 2 finishes before Actor 1 starts, Actor 1 would disregard the request and report success.
-    c. If Actor 1 and Actor 2 simultaneously and successfully write the same transaction, a result of is two siblings.
+    1. If the Actor 1 is successful in writing the transaction before Actor 2 begins, Actor 2 will see that the transaction id already exists, and will return successful before attempting to write.
+    2. Similarly, if Actor 2 finishes before Actor 1 starts, Actor 1 would disregard the request and report success.
+    3. If Actor 1 and Actor 2 simultaneously and successfully write the same transaction, a result of is two siblings.
 2. If 1a or 1b happen, there is no problem. If 1c occurs, the second line of defense happens during a merge (merges are triggered prior to every write, and after every read).
-    a. If Actor 1 merges before Actor 2, Actor 1 will remove it's own duplicate transaction in favor of leaving Actor 2's version, knowing it cannot modify any other actors' data.
-    b. Similarly, if Actor 2 merges before Actor 1, it will remove it's own duplicate transaction.
-    c. If Actor 1 and Actor 2 merge simultaneously and successfully, they would both remove their own duplicate (from their point of view) version of the transaction, meaning it would be lost causing negative counter drift (on increments) and positive drift (on decrements)
+    1. If Actor 1 merges before Actor 2, Actor 1 will remove it's own duplicate transaction in favor of leaving Actor 2's version, knowing it cannot modify any other actors' data.
+    2. Similarly, if Actor 2 merges before Actor 1, it will remove it's own duplicate transaction.
+    3. If Actor 1 and Actor 2 merge simultaneously and successfully, they would both remove their own duplicate (from their point of view) version of the transaction, meaning it would be lost causing negative counter drift (on increments) and positive drift (on decrements)
 
 This is an unlikely but possible scenario. Here are some ways to reduce or elimiate the possibility of 2c from happening:
 
 1. The precursor to the condition resulting from 2c can be avoided by serializing writes per transaction, like in the example of a game's application server knowing to only submit one unique transaction at a time. Submitting simultaneous transactions is ok, so long as the same transaction isn't active in more than one actor at the same time.
-    a. This is possible using this gem, it's just a matter of implemeting some control over who can write a single unique at the same time.
+    1. This is possible using this gem, it's just a matter of implemeting some control over who can write a single unique at the same time.
 2. Have a no duplicate delete policy, meaning that you could potentially have an infinitely growing list of duplicate transactions if your application causes this situation often.
-    a. This is unimplemented in this gem as of now, but depending on the thoughts of others, I may add it as an optional policy.
+    1. This is unimplemented in this gem as of now, but depending on the thoughts of others, I may add it as an optional policy.
 3. Attach a microsecond epoch to each transaction so that during merges the the duplicate transaction with the highest epoch always wins.
-    a. This is unimplemented in this gem, and it would only lessen the statistical likelihood of 2c happening, it would still be possible. Because it only lowers the likelihood.
-4. Do a string compare on the actor ids, whichever has the highest string compare value always keeps it's version of the duplicate transaction.
-    a. This is now implemented in version 0.1.0, see below.
+    1. This is unimplemented in this gem, and it would only lessen the statistical likelihood of 2c happening, it would still be possible. Because it only lowers the likelihood.
+4. Do a string compare on the actor ids, whichever has the highest string compare value always keeps it's version of the duplicate transaction. If one the lesser actor is stale and never merges, the actor that should keep the transaction will throw it away knowing that the stale actor will keep it.
+    1. This is now implemented in version 0.0.5, see below.
 
 ##### Version 0.0.5 and Actor Naming [***Important***]
 
@@ -30,4 +30,8 @@ Solution 4 has been implemented to the potential counter drift caused by two sim
 
 As a result, keep in mind that when naming actors, they will be compared for ordering purposes
 
-Example: "ACTOR2" is greater than "ACTOR1", so ACTOR1 will always remove it's version of a duplicate transaction during a merge, and "ACTOR2" will never remove it's version. Avoid using actor ids that could potentially result in string equality.
+Example: "ACTOR2" is greater than "ACTOR1", so ACTOR1 will always remove it's version of a duplicate transaction during a merge, and "ACTOR2" will never remove it's version unless it thinks actor 1 is stale. Avoid using actor ids that could potentially result in string equality.
+
+##### Version 0.0.5
+
+Removed the automatic setting of allow_mult on the bucket in Riak::Ledger. Please remember to set allow_mult to true on your ledger bucket, notes in README.md

data/lib/ledger.rb

@@ -16,6 +16,8 @@ module Riak
     #     :retry_count [Integer]: default 10
     #   }
     def initialize(bucket, key, options={})
+      raise ArgumentError, 'Argument "bucket" must have "allow_mult" property set to true' unless bucket.allow_mult
+
       self.bucket = bucket
       self.key = key
       self.retry_count = options[:retry_count] || 10
@@ -24,10 +26,6 @@ module Riak
       self.counter_options[:actor] = options[:actor] || Thread.current["name"] || "ACTOR1"
       self.counter_options[:history_length] = options[:history_length] || 10
       self.counter = Riak::CRDT::TPNCounter.new(self.counter_options)
-
-      unless bucket.allow_mult
-        self.bucket.allow_mult = true
-      end
     end
 
     # Find an existing Ledger object, merge and save it

data/lib/ledger/version.rb

@@ -1,5 +1,5 @@
 module Riak
   class Ledger
-    VERSION = "0.0.5"
+    VERSION = "0.0.6"
   end
 end

data/test/lib/ledger_test.rb

@@ -9,6 +9,7 @@ describe Riak::Ledger do
   before do
     client = Riak::Client.new pb_port: 8087
     @bucket = client["ledger_test"]
+    @bucket.allow_mult = true
     @key = "player_1"
 
 
@@ -21,8 +22,17 @@ describe Riak::Ledger do
     @ledger2.delete()
   end
 
-  it "have a valid starting state" do
+  it "must raise an error if mult is not allowed" do
+    @bucket.allow_mult = false
+
+    assert_raises ArgumentError do
+      Riak::Ledger.new(@bucket, @key, options1)
+    end
 
+    @bucket.allow_mult = true
+  end
+
+  it "have a valid starting state" do
     assert_equal({:type=>"TGCounter", :c=>{"ACTOR1"=>{"total"=>0, "txns"=>[]}}}, @ledger1.counter.p.to_hash)
     assert_equal({:type=>"TGCounter", :c=>{"ACTOR1"=>{"total"=>0, "txns"=>[]}}}, @ledger1.counter.n.to_hash)
   end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: riak-ruby-ledger
 version: !ruby/object:Gem::Version
-  version: 0.0.5
+  version: 0.0.6
 platform: ruby
 authors:
 - drewkerrigan
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-12-21 00:00:00.000000000 Z
+date: 2013-12-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler