Field added after the requested version is exempt from versioning

[CarlLooksUp]

I start with some object

$ o = MyModel.create(a: 1, b: 2)

I add column c to MyModel in a migration

$ ap o
<MyModel: 0x00000> {
  :a => 1,
  :b => 2,
  :c => nil,
  :log_data => #<Logidze....>
}

I change the value of c

$ o.update(c: 3)

I request the initial version and expect to see the default value of c

$ o.at_version(1).c
3

Instead I see the most recent value of c.

Is this expectation reasonable? Is there a way to support this behavior if not by default then through configuration?

[palkan]

Is this expectation reasonable?

Interesting case.

Your initial snapshot (version 1) doesn't contain c column value at all, that's why it hasn't been reset.
During the rollback we simply apply all the required diffs to the initial snapshot. Since none if the diffs contains c, the value stays the same.

expect to see the default value of c

Why default? Do you have not null constraint? In that case it make sense. Otherwise, it make sense to return nil.

Frankly speaking, I don't know whether Postgres invokes UPDATE triggers when you add a new not-null column with the default value. If that's true, than we should have a log entry.

To sum up, we do not handle adding/removing columns right now. I'll create a separate issue.

[palkan]

@CarlLooksUp See #59

[palkan]

Closed in favour of #59