Hey Jeremy,
Ok, that makes sense, sounds like I should peruse the release notes; just
to see what else has changed.
To my other question, where would the "raw" data be stored if not in the
values hash? I'm just interested where the "true" value is coming from in
the newly instantiated company.
Thanks for the prompt answer by the way.
-Robert
On Wednesday, May 14, 2014 11:02:34 AM UTC-4, Jeremy Evans wrote:
>
> On Wednesday, May 14, 2014 6:45:27 AM UTC-7, Robert Sosinski wrote:
>>
>> Hello,
>>
>> Migrating from Sequel 3.48.0 to 4.10.0 and noticed a difference with how
>> the defaults_setter plugin on Sequel::Model works.
>>
>> I have a Postgres 9.3 database column called "active" with is boolean of
>> "not null" and "default true". Previously, on 3.48.0 and the defaults
>> setter plugin, a new Company would look like this in console:
>>
>> c = Company.new
>> => #<Company @values={:active=>true}>
>> c.values
>> => {:active=>true}
>> c.values[:active]
>> => true
>> c.active
>> => true
>>
>> However now on 4.10.0, it looks like this
>>
>> c = Company.new
>> => #<Company @values={}>
>> c.values
>> => {}
>> c.values[:active]
>> => nil
>> c.active
>> => true
>>
>> Notice how the company is still defaulting to active being true, but that
>> data is not in the values hash anymore. As such, it is behaving somewhat
>> inconsistently. Also, if the data is not in the #values hash, where is it
>> being stored for the #active method?
>>
>
> As explained the 4.0.0 release notes (and preannounced in the 3.48.0
> release notes), defaults_setter now works in a lazy manner, so this is
> expected.
>
> I don't see this as inconsistent, as you should not expect
> c.values[:column] to match c.column. With a number of plugins that will
> not be the case. In general you should not be accessing the values hash
> directly unless you have a good reason too.
>
> The main reason behind the change is that it fixes the handling of current
> timestamp defaults. Previously, because it was set in values, you would
> end up with the current timestamp on object instantiation, as opposed to
> the current timestamp on the start of the database transaction in which the
> row is inserted. This broke correct transactional handling of timestamps.
> The new way also makes instantiation significantly faster.
>
> Thanks,
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
