Re: How to handle bogus nulls from ActiveRecord

Поиск
Список
Период
Сортировка
От James B. Byrne
Тема Re: How to handle bogus nulls from ActiveRecord
Дата
Msg-id 59623.216.185.71.25.1305220447.squirrel@webmail.harte-lyne.ca
обсуждение исходный текст
Ответ на Re: How to handle bogus nulls from ActiveRecord  ("David Johnston" <polobo@yahoo.com>)
Ответы Re: How to handle bogus nulls from ActiveRecord
Список 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@Harte-Lyne.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


В списке pgsql-general по дате отправления:

Предыдущее
От: "David Johnston"
Дата:
Сообщение: Re: How to handle bogus nulls from ActiveRecord
Следующее
От: bubba postgres
Дата:
Сообщение: pg_dump on Hot standby : clarification on how to