Re: Proposed workflow for upgrade wizard for 1.2 to 1.3

[Chris Travers <..hidden..>]

On Tue, Jul 19, 2011 at 10:08 AM, Michael Richardson <..hidden..> wrote:
>
>>>>>> "Chris" == Chris Travers <..hidden..> writes:
>    Chris> Screen 2: We will now check out your database for problems
>    Chris> that might interfere with the upgade.  (run queries to check
>    Chris> against new unique constraints that are known to be
>    Chris> problematic.  If problem found go to three, if no problem
>    Chris> found go to 4)
>
> A lingering problem I have had, which I've never solved, was that at
> some point in sql-ledger history, OIDs became required, but I didn't
> have them.  I think I've fixed all the relevant tables, but probably not
> all of them.
> I'm not asking you to fix things, but tell me.

1.2.x shouldn't require OID'd anywhere.

What probably happened here is that OID's were probably required for a
long time as PostgreSQL used to always create them.  Then with newer
PostgreSQL versions, this was dropped, and made a non-default option.
This was to prevent problems in large PostgreSQL databases with OID
wraparound.

The new checks in 1.3 deal mostly with new unique constraints, and
issues of information completeness on migration.  Some of the issues
are not specifically issues with unique constraints in 1.3 so much as
data mappings coming in (for example, unique vendor numbers are
required during migration due to internal control codes being
required, but this could be revisited if it becomes a problem).
>
>    Chris> Screen 3: Problem found....  List problem records.  Give an
>    Chris> opportunity to correct the problem in non-destructive way.
>    Chris> Then continue running query checks, For each problem found
>    Chris> repeat this screen.  When no more problems found, go to
>    Chris> screen 4.  Note this will not correct some problems (missing
>    Chris> or unrecognized countries) which will be addressed
>    Chris> post-migration.
>
> good...
> In some cases, it may be reasonable for someone to fix the database
> directly,  so please don't cache too much, and recheck old problems.

Of course.
>
>    Chris> Feedback?
>
> I'd love to have this in a test framework.

What specific use case do you have in mind?  Just testing the
migration scripts and queries?  Or being able to use a test famework
to check your old data?

Best Wishes,
Chris Travers