Search Postgresql Archives

Re: How to handle bogus nulls from ActiveRecord

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Well, actually, the reason for the NOT NULL constraint is to catch
application errors exactly like this one. Removing it is not
contemplated.  I had no idea that AR actually 'copied' and used
default values on columns that were not referenced in the
application code until I encountered this.  And had it gone
undetected this would have been a major problem later on.  As it
was, our tests brought it to our attention quite early which is why
we can contemplate several solutions.

> Without more info as to how you use "expected_at" other
> advice is difficult but can you user a meaningful value
> (say now()+'30 days'::interval) for the default?

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.

Conveyances that have +infinite expected_by time-stamps are
considered pending.  At some point conveyance rows that are never
going to arrive are otherwise flagged.  On the other hand, rows with
overdue expected_by values are given somewhat more attention, to put
it mildly.  So, we either fix the problem with AR, possibly by
moving to Sequel ORM for this case, although I have not yet received
an answer as to whether it does any better;  Or we trap and override
NULL values with infinity in a trigger; Or we choose for the default
value a fixed date far, far into the future.

+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 9999-12-31 and treat that value
like infinity.

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux