trafodion-codereview mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robertamarton <...@git.apache.org>
Subject [GitHub] incubator-trafodion pull request #661: [TRAFODION-2161] Support migration of...
Date Thu, 18 Aug 2016 01:03:50 GMT
Github user robertamarton commented on a diff in the pull request:

    https://github.com/apache/incubator-trafodion/pull/661#discussion_r75234375
  
    --- Diff: core/sql/sqlcomp/CmpSeabaseDDLrepos.cpp ---
    @@ -516,6 +585,62 @@ short CmpSeabaseDDL::upgradeReposComplete(ExeCliInterface * cliInterface,
     
             case 1:
               {
    +            // If there were views on the old Repository tables, they are
    +            // still there, by virtue of the fact that we did "SKIP VIEW CHECK"
    +            // on the ALTER TABLE RENAME. Now we will capture their view
    +            // definitions (which will contain the old table name, not the
    +            // renamed table name) and replay that against the new Repository
    +            // table. If the replay fails, we treat that as an unrecoverable
    +            // situation and ignore it. Instead, we'll save the view definition
    +            // text in the TEXT table with a different TEXT_TYPE and clue the
    +            // user in that it is there. They can then try to create the view
    +            // at their leisure. Note that they may have to change the view
    +            // definition themselves, e.g. if we dropped a column from the
    +            // repository table that their view happened to reference.
    +            //
    +            // Note that this work is done in one step because the only state
    +            // we can depend upon across redrives to this method is the substep
    +            // number. Any in-memory list would be lost across redrives.
    +            NABoolean someViewSaved = FALSE;
    +            migrateReposViews(cliInterface,someViewSaved /* out */);
    +
    +            mdui->setMsg("Upgrade Repository: View migration done");
    +            if (someViewSaved)
    +              mdui->subStep()++;
    +            else
    +              mdui->subStep() += 2;
    +
    +            mdui->setEndStep(FALSE);
    +       
    +            return 0;
    +          }
    +          break;
    +
    +        case 2:
    +          {
    +            // This state is here in case we want to report to the user that
    +            // there was a view that could not be migrated. But we saved the
    +            // view definition for that view in the TEXT table.
    +            mdui->setMsg("Some user views could not be migrated. Check metadata TEXT
table, TEXT_TYPE = 9.");
    +            mdui->subStep()++;
    --- End diff --
    
    From the previous code, it looks like text_uid is -2?   The primary key of TEXT (if memory
serves correct) is the text_uid, text_subid, seq_num and text_type.   Will there be conflicts
if two or more views are required to be saved both with a UID of -2?  If someone does not
cleanup view text before running upgrade for a future release, will there be conflicts?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message