Re: How to handle bogus nulls from ActiveRecord

From: "James B(dot) Byrne" <byrnejb(at)harte-lyne(dot)ca>
To: "David Johnston" <polobo(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: How to handle bogus nulls from ActiveRecord
Date: 2011-05-12 17:14:07
Message-ID: 59623.216.185.71.25.1305220447.squirrel@webmail.harte-lyne.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


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(at)Harte-Lyne(dot)ca
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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message bubba postgres 2011-05-12 18:26:38 pg_dump on Hot standby : clarification on how to
Previous Message David Johnston 2011-05-12 16:40:26 Re: How to handle bogus nulls from ActiveRecord