On 12/9/18 10:47 AM, Mike Lissner wrote:
>
> My contention is that for all these reasons, there should *never* have
> been a null value in that column on master.
>
>
> > column ever had a null value and I tried to run a DDL to add a null
> > constraint, the DDL would have failed, right?
> >
> > Something feels wrong here, the more I think about it.
>
> A start would be to figure out what generated?:
>
> failing row contains (48064261, 2018-12-07 04:48:40.388377+00,
> 2018-12-07 04:48:40.388402+00, null, 576, , 4571214, null, null)
>
>
> Yes, I completely agree. I can't think of any way that that should have
> ever been created.
1) Using psql have you verified that NOT NULL is set on that column on
the publisher?
2) And that the row that failed in the subscriber is in the publisher table.
3) That there are no NULL values in the publisher column?
Whatever the answers to 1), 2) and 3) are the next question is:
4) Do you want/need recap_sequence_number to be NOT NULL.
a) If not then you could leave things as they are.
b) If so then you:
1) Have to figure out what is sending NULL values to the column.
Maybe a model that has null=True set when it shouldn't be?
A Form/ModelForm that is allowing None/Null?
Some code that is operating outside the ORM e.g. doing a
direct query using from django.db import connection.
2) Clean up the NULL values in the column in the subscriber
and/or publisher.
>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
