TalentBox/sequel_bitemporal — pull request #1 by koendehondt (2013-07-10 10:18:04+00:00)
Title: Spec fixes

I noticed that the have_versions matcher did not take all columns into account that were used in the specs. The "can propagate changes to future versions per column" example in bitemporal_date_spec.rb (line 338) states expectations on the length and the width attributes, but they were not used in the matcher.
So I generalized the matcher to take all columns of an expectation into account. That is the first commit.

However, by taking all columns into account, the "can propagate changes to future versions per column" example is not green anymore. In the second commit, I changed the expectation, but I am not sure that it is the right fix, because I wonder about the behaviour of the bitemporal plugin.

The example states that a version with a valid_from equal to the current date (here set by Timecop.freeze) is also changed when the valid_from in the call to update_attributes is smaller. Line 351-353 reads:
```ruby
Timecop.freeze initial_today+3 do
master.update_attributes valid_from: initial_today+2, length: 3, width: 4
end
```
and the expectation on line 363 reads (after my change where 1 in the third column is changed in 3):
```
| Single Standard | 12 | 3 | 4 | 2009-12-01 | | 2009-12-01 | 2009-12-02 | |
```
So the example states that if there is a version V1 and we freeze the time to V1's valid_from and we call update_attributes with valid_from smaller than V1's valid_from, a V2 is created before V1 and the attribute changes are propagated to V1. Is that the intended behaviour? If so, what is the rationale?