infochimps-labs / gorillib Goto Github PK

A simple line that used to work (taken from the internal documentation in lib/gorillib/model/base.rb):

class Person
  include Gorillib::Model

  field :name,   String,  :doc => 'Full name of person'
  field :height, Float,   :doc => 'Height in meters'
end

now breaks with an apocryphal error message:

ArgumentError: visibility must be one of [:public, :private, :protected]: got nil
    from /Users/travis/.rvm/gems/ruby-1.9.2-p290/gems/gorillib-0.5.0/lib/gorillib/model/named_schema.rb:30:in `define_meta_module_method'
    from /Users/travis/.rvm/gems/ruby-1.9.2-p290/gems/gorillib-0.5.0/lib/gorillib/model/schema_magic.rb:103:in `define_attribute_reader'
    from /Users/travis/.rvm/gems/ruby-1.9.2-p290/gems/gorillib-0.5.0/lib/gorillib/model/field.rb:102:in `inscribe_methods'
    from /Users/travis/.rvm/gems/ruby-1.9.2-p290/gems/gorillib-0.5.0/lib/gorillib/model/schema_magic.rb:27:in `field'

Looking at the documentation (README.md, the classes in lib/gorillib/model) yields no answer. Is this a "feature" or a bug?

I'm not going to dive in too deep, but I am getting nasty stack traces from deep within multi json when calling to_wire on models without having required 'gorillib/serialization/to_wire'. Flip seems to understand what is going on.

Here's the stacktrace. Ignore anything in /usr/local/flume/infomart/{app,src}, because the code was all fixed before being committed.

NoMethodError: undefined method `delete' for #JSON::Ext::Generator::State:0x22426f2d
current_adapter at /usr/local/flume/infomart/bundle/jruby/1.9/gems/multi_json-1.3.7/lib/multi_json.rb:105
dump at /usr/local/flume/infomart/bundle/jruby/1.9/gems/multi_json-1.3.7/lib/multi_json.rb:114
to_json at /usr/local/flume/infomart/bundle/jruby/1.9/gems/gorillib-0.4.2/lib/gorillib/model/serialization.rb:18
to_json at json/ext/GeneratorMethods.java:71
dump at /usr/local/flume/infomart/bundle/jruby/1.9/gems/multi_json-1.3.7/lib/multi_json/adapters/json_common.rb:11
dump at /usr/local/flume/infomart/bundle/jruby/1.9/gems/multi_json-1.3.7/lib/multi_json.rb:115
to_json at /usr/local/flume/infomart/bundle/jruby/1.9/gems/gorillib-0.4.2/lib/gorillib/model/serialization.rb:18
emit at /usr/local/flume/infomart/src/main/ruby/base_processor.rb:43
process at /usr/local/flume/infomart/app/processors/entry_funnel.rb:119
_append at /wukong-flume/framework.rb:86

!! 0 returns true and this is counterintuitive. If I have explicitly set a field to be a Boolean, receiving a 0 should be understood as false.

1. compact_attributes does return "nil but set" attributes. This differs from attributes.compact, which is surprising behavior.
2. unset_attributes should exist, with the current functionality of compact_attributes, and...
3. unset_attributes should trigger the firing of the defaults, because...
   • otherwise calling or not calling attributes and then compact_attributes give different behavior; this should be addressed by...
4. attribute_set? should return true for a field with a default.
   • this is somewhat controversial, but if you believe as flip does that an attribute with a default has always had that value, just lazily evaluated then the behavior is correct.

Bug atually filed by flip, so if TD disagrees he may follow up...

Run the following script

require 'gorillib/model'
class Foo
  include Gorillib::Model
  field   :boolsy, :boolean
end
[true, false, 'true', 'false', '0', '1', 0, 1,].each do |thing|
  puts [thing.inspect, Foo.receive(boolsy: thing).boolsy.to_s].join("\t")
end

Using latest Gorillib (0.5.0) I see

$ ruby bool_test.rb
true    true
false   false
"true"  true
"false" false
"0"     true
"1"     true
0       true
1       true

Shouldn't the behavior be to default to interpret 0 and "0" as false and 1 and "1" as true? Or is the belief that this pattern is "not common or reliable enough to encode in a library"?

Positional arguments break when the last argument is a Hash:

# This does not work as expected
class Foo
  include Gorillib::Model

  field :name, String, position: 0
  field :info, Hash, position: 1
end

f = Foo.new('joebob', { boring: true })
f.name
#=> "joebob"
f.info
#=> nil

This can be solved by either not having a Hash as the last positional argument, or by passing in the (apparently not optional) options hash whenever using the #new method with positional args. Neither is a great alternative:

# Never put Hashes last in positional argument lists
class Foo
  include Gorillib::Model

  field :name, String, position: 1
  field :info, Hash, position: 0 # Reorganize the positions to avoid problems
end

f = Foo.new({ boring: true }, 'joebob')
f.name
#=> "joebob"
f.info
#=> {:boring=>true}

# Or alternatively

class Foo
  include Gorillib::Model

  field :name, String, position: 0
  field :info, Hash, position: 1
end

f = Foo.new('joebob', { boring: true }, {}) # Always remember this empty options hash
f.name
#=> "joebob"
f.info
#=> {:boring=>true}

The culprit is the #extract_options! method here.

• context "receiving referenced types" do
  • it "should be able to identify the referenced type specified"
  • it "should add the referenced type to the array of types for this protocol"
• context "receiving is_a" do
  • it "should populate the fields array with the referenced type's fields"
  • it "should allow additional field definitions to be added after the receive"
  • it "should override referenced fields when a field is defined with the same name"
• context "receiving identifier" do
  • it "should be able to return all field definitions specified as identifiers"
• context "receiving domain_id" do
  • it "should be able to return the field definition specified as the domain_id"
• context "receiving validates" do
  • it "should be able validate the received values using the specified active model validators"
• context "Icss::Klasses" do
  • it "should be able to return its values with dotted accessors"
    end
• context "transformation" do
  • it " should be able to transform itself into a GeoJson object"
• context "transformation receiving aspects" do
  • it "should be able to generate a class form its apect's typing"
  • it "should receive the aspect's properties first"
  • it "should receive the original Icss::Klass properties"
  • it "should receive the original Icss::Klass as an aspect, inlcuding left over properties"

(paging @kornypoet)

Making deep_compact preserve type -- {}.deep_compact should be {} not nil, to remain parallel with .compact.

What happens to undefined extra args in the receiving hash?

class Foo
  include Receiver
  rcvr_accessor :name, String
end

Foo.receive( { :name=>"Travis", :age=>26 } )
=> #<Foo:0x10059be78 @name="Travis">

Where did :age go? @mrflip

Why is this? I want #receive! to return self like #update_attributes and .receive but it returns nil instead. What is the reasoning behind this? Also, why does #update_attributes NOT handle extra attributes? I have to work around all of these issues.