[GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-12 Thread James B. Byrne
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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-12 Thread David Johnston
> -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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-12 Thread James B. Byrne
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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-12 Thread David Johnston
> 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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-12 Thread James B. Byrne
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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-12 Thread Eric Hu
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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-13 Thread James B. Byrne
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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-13 Thread Dickson S. Guedes
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

Re: [GENERAL] How to handle bogus nulls from ActiveRecord

2011-05-13 Thread James B. Byrne
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