I had a request this morning from a client who wanted me to save some tables from their database as CSVs. They provided a .pgsql file which contains all the data and instructions for constructing the database. It’s sort of a bunch of migrations and seeds in one place.
There might be a more straightforward way but I decided to create a new Rails app and build the database from the dump file. I could then export the tables from the console.
There weren’t many steps to it. Firstly I created the database.
I went to config/database.yml to get the name of the database before running:
psql -d rails_app_development -f dumped_db.pgsql
It took a couple of tries. The command’s output informed me I needed to create some users:
It took me an hour or so of frustration to figure out why a method was being called multiple times despite my attempt at memoizing its return value.
My problem looked a bit like this.
My intention was that value of post_complete? would be stored as @happy so that post_complete? would be fired only once.
However, that’s not guaranteed to happen here. post_complete? might be evaluated and its value assigned to @happyevery time I call happy?.
Can you see why?
What’s going on?
The question mark denotes that post_complete? is expected to return a boolean value. But, what if that value is always false?
Another way of writing the statement is:
In the above example, I want to know if at least one of the sides is true.
Remember that if the left-hand side of an || statement is false, then the right-hand side is evaluated. If the left side is truthy, there’s no need to evaluate the right side – the statement has already been proven to be true – and so the statement short circuits.
If I replace post_complete? with boolean values, it’s easier to see what is happening.
In this example, @happy becomes true:
defhappy?@happy||@happy=true# @happy == trueend
However, in this example, @happy becomes false:
defhappy?@happy||@happy=false# @happy == falseend
In the former, @happy is falsey the first time the method is called, then true on subsequent calls. In that example, the right-hand side is evaluated once only. In the latter, @happy is always false and so both sides are always evaluated.
When using the ||= style of memoization, only truthy values will be memoized.
So the problem is that if post_complete? returns false the first time happy? is called, it will be evaluated until it returns true.
So how do I go about memoizing a false value?
Instead of testing the truthiness of @happy, I could check whether or not it has a value assigned to it. If it has, I can return @happy. It if hasn’t, then I will assign one. I will use Object#defined?.
defined? expression tests whether or not expression refers to anything recognizable (literal object, local variable that has been initialized, method name visible from the current scope, etc.). The return value is nil if the expression cannot be resolved. Otherwise, the return value provides information about the expression.
Referring back to the documentation, there’s one thing I need to be aware of. This isn’t the same as checking for nil or false. It’s a bit counterintuitive, but defined? doesn’t return a boolean. Instead, it returns information about the argument object in the form of a string:
I now know that the ||= style of memoization utilizes short-circuiting. If the left-hand side variable is false, then the right-hand part of the statement will be evaluated. If that’s an expensive method call which always returns false, then the performance of my program would be impacted. So instead of ||= I can check if the variable is initialized or I can check if it’s nil.
A small simple object, like money or a date range, whose equality isn’t based on identity.
Objects in Ruby are usually considered to be entity objects. Two objects may have matching attribute values but we do not consider them equal because they are distinct objects.
In this example a and c are not equal:
classPanserbjorndefinitialize(name)@name=nameendenda=Panserbjorn.new('Iorek')b=Panserbjorn.new('Iofur')c=Panserbjorn.new('Iorek')a==c#=> => false# Three distinct objects:a.object_id#=> 70165973839880b.object_id#=> 70165971554200c.object_id#=> 70165971965460
Value objects on the other hand, are compared by value. Two different value objects are considered equal when their attribute values match.
Symbol, String, Integer and Range are examples of value objects in Ruby.
Here, a and c are considered equal despite being distinct objects:
a='Iorek'b='Iofur'c='Iorek'a==b#=> falsea==c#=> true# Three distinct objects:a.object_id#=> 70300461022500b.object_id#=> 70300453210700c.object_id#=> 70300461053840
How can I create a value object?
Say I want a class to represent the days of the week and I also want instances of that class to be considered equal if they represent the same day. A Sunday object should equal another Sunday object. A Monday object should equal another Monday object, etc…
I have aliased #eql? to #==. The BasicObjectdocumentation explains:
For objects of class Object, eql? is synonymous with ==. Subclasses normally continue this tradition by aliasing eql? to their overridden ==
Bingo! We have value objects. pizza_day and recycling_collection_day are considered equivalent:
I could override other comparison methods, #<==>. <=, <, ==, >=, > and between? as it makes sense to say that Monday is less than Tuesday or Friday is greater than Thursday but I have decided that’s not needed for now.
There is however, one more important step that I need to implement. These objects are equivalent, so when used as a hash key I would expect them to point to the same bucket.
a='Svalbard'b='Svalbard'# Note the different object ids:a.object_id#=> 70253833847520b.object_id#=> 70253847146940'Svalbard'.object_id#=> 70253847210020# The hash values of equivalent strings match:'Svalbard'.hash=='Bolvanger'.hash#=> false[a,b,"Svalbard"].map(&:hash).uniq.count#=> 1'Svalbard'.hash==('Sval'+'bard').hash#=> true
I will generate the hash using its string and integer properties.
We now know the difference between an entity object and a value object. We have learned that we need to override both #hash and #== if our value objects are to be used as hash keys. And, we have learned that structs provide value object behaviour straight out of the box.