bugfix - Changing from singleton model to returning query object (which is lazy eval'ed)

[sidazhang]

Background

1. This pull request is to follow up on Can't assign API response to variable #4
2. Some preliminary thoughts were shared here: https://gist.github.com/sidazhang/cb1ee9a2526b3eb382a9

Details

The design of the library rests on a singleton module where there is one module level variable that keeps track of the state. This combined with lazy eval means that it returns itself (as a class) into a variable.

However, because the query is only fired upon to_hash or [], the stateful nature of lazy eval combined with a module level variable which must be cleared upon every call means that this doesn't work very nicely. Everytime you call the variable, it will make another api call (except without the params since its already cleared)

response = HelloBlock::Transaction.find(tx)
p response.class == HelloBlock::Transaction
# since response is the class itself, everytime you use the variable it will make another call

Proposed solution

This is a proof of concept pull request which turns module Query into a class Query and have resource classes (such as Transaction, Address etc) inherit from it. Each call returns an instance which also keeps track of state such as what is the query params, and whether the call has been made and cached.

Tests

All the integration tests passed (so we know this works) although some of the unit tests are still failing. Since this is a structural change to the library I don't expect many of the unit tests to still be relevant.

➜  helloblock git:(bugfix-singleton) rspec spec/integration/api_calls_work_spec.rb
You are using WebMock 1.16.1. VCR 2.8.0 has been tested against WebMock >= 1.8.0, < 1.16, and you are using a newer version. If you experience VCR issues, consider downgrading WebMock as it may fix it.
..................

Finished in 0.159 seconds
18 examples, 0 failures

[sidazhang]

Update:

I have worked on this a bit more. Currently, all the tests are passing. Since we no longer use a singleton model (rather, we use class methods to create instances). We no longer kickers to clear query cache

[sidazhang]

Connection Caching was removed because if we change network half way the connection is already cached and new connection a different network would not be established

[sidazhang]

@NathanielWroblewski,

new weird bug:
When I am in the console and I print the response in line, the execution of this timesout.

response = HelloBlock::Address.where(addresses: ['1DQN9nopGvSCDnM3LH1w7j36FtnQDZKnej']); p response

irb(main):002:0> response = HelloBlock::Address.where(addresses: ['1DQN9nopGvSCDnM3LH1w7j36FtnQDZKnej']); p response
{"status"=>"fail", "message"=>"There are 1 invalid addresses", "details"=>["1DQN9nopGvSCDnM3LH1w7j36FtnQDZKnej"]}
Net::OpenTimeout: execution expired
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:662:in `write'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:662:in `printf'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:662:in `output_value'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:493:in `block (2 levels) in eval_input'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:624:in `signal_status'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:489:in `block in eval_input'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:247:in `block (2 levels) in each_top_level_statement'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:233:in `loop'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:233:in `block in each_top_level_statement'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:232:in `catch'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:232:in `each_top_level_statement'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:488:in `eval_input'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:397:in `block in start'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:396:in `catch'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/irb.rb:396:in `start'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/cli.rb:619:in `console'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/vendor/thor/task.rb:27:in `run'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/vendor/thor/invocation.rb:120:in `invoke_task'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/vendor/thor.rb:344:in `dispatch'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/vendor/thor/base.rb:434:in `start'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/bin/bundle:20:in `block in <top (required)>'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/friendly_errors.rb:3:in `with_friendly_errors'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/bin/bundle:20:in `<top (required)>'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/bin/bundle:23:in `load'
    from /Users/alumn/.rbenv/versions/2.0.0-p247/bin/bundle:23:in `<main>'Maybe IRB bug!

[sidazhang]

Update

Defaults to mainnet rather than testnet and updated test fixtures

[sidazhang]

@NathanielWroblewski, The problem with def inspect is worse than unexpected. Connection times out whenever we p response before the query has been executed.

[NathanielWroblewski]

Sorry for the late responses. I am in New York for a few days and without internet. I will look at this as soon as I return. Hopefully, it is not too late by then.

[sidazhang]

ok breh. Take a rest!