It is required for application data verification filters that
default values for table columns are known to ActiveRecord when
creating a new row. So ActiveRecord obtains the default values from
the tables dynamically and assigns them to their appropriate column
attributes. The problem we encounter
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of James B. Byrne
> Sent: Thursday, May 12, 2011 9:12 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] How to handle bogus nulls from Activ
On Thu, May 12, 2011 12:40, David Johnston wrote:
>
> Not a huge fan of Infinity as a value...but that just may be lack of
> experience.
>
> I'd probably remove the NOT NULL constraint on expected_at and deal
> with tri-value logic; or also include a boolean (is_expected) and
> form queries like
> The column expected_by contains an estimated time of arrival for a
particular
> conveyance. When a row is initialized this value is unknown some of the
> time. The expected_by value is reset to the arrived_at value on UPDATE if
> and only if expected_by is greater than arrived_at.
>
> Conveyanc
On Thu, May 12, 2011 15:51, David Johnston wrote:
>>
>> +Infinity was chosen as a default to avoid the complexities of
>> dealing with NULL logic in SELECTS. I suppose that the simplest
>> solution is to go with a date of -12-31 and treat that value
>> like infinity.
>
> The "just make it wor
David suggested using a guesstimate default date along with a boolean to
indicate when you're using guesstimates. I think this is a solid approach,
but if the default expected_by idea doesn't work for you, a boolean would
still make this a lot easier on the Rails side.
It sounds like you're using
On Thu, May 12, 2011 20:30, Eric Hu wrote:
> David suggested using a guesstimate default date along with
> a boolean to indicate when you're using guesstimates.
> I think this is a solid approach, but if the default
> expected_by idea doesn't work for you, a boolean
> would still make this a lot e
2011/5/13 James B. Byrne :
> Actually, it turn out that 'infinity' is supported in Ruby.
> Apparently infinity can be represented by assigning the value
> obtained by dividing a float by zero.
>
> $ irb
> ruby-1.8.7-p334 :001 > infinity = 1.0/0
> => Infinity
> ruby-1.8.7-p334 :002 > ninfinity = -1
On Fri, May 13, 2011 11:50, Dickson S. Guedes wrote:
>
> Well, fetching from database it came nil and when saved into, it was
> trying to save a serialized object. From postgresql_adapter.rb [1]
> you
> can see that it returns the correct internal type based when field
> type is datetime, but i c
