----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/51137/#review146771 -----------------------------------------------------------
tools/src/main/java/org/apache/oozie/tools/OozieDBImportCLI.java (line 120) <https://reviews.apache.org/r/51137/#comment213431> It would worth to check whether Oozie database tables exist and they are empty. If they are not empty, then notify the user and fail the import process. As of now, if we try to import the database twice, import will fail due key uniqueness violation (cannot insert it with the same primary key). However, let's say we exported/dumped 2 different Oozie databases in different dump files. Then if the primary keys are different in the dump files, then we can populate a database that consists rows from both databases. It would be a quite unfortunate situation. This extra validation can be implemented in a followup JIRA, if it is a huge modification. - Attila Sasvari On Aug. 16, 2016, 2:04 p.m., Peter Cseh wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/51137/ > ----------------------------------------------------------- > > (Updated Aug. 16, 2016, 2:04 p.m.) > > > Review request for oozie. > > > Bugs: OOZIE-2632 > https://issues.apache.org/jira/browse/OOZIE-2632 > > > Repository: oozie-git > > > Description > ------- > > When there is a need to change the database under Oozie one has to submit all > the workflows again or migrate the data manually which is not easy because of > the binary blobs stored in the DB. > oozie-setup.sh could have a db export/import command that would save the > contents of the Db to a file and read it back from it. Functionality added > with some tests. The database is dumped using GSON to json files and zipped > to a single file to use less disk space. > > > Diffs > ----- > > distro/src/main/bin/oozie-setup.ps1 ca89b88 > distro/src/main/bin/oozie-setup.sh 3b6a643 > pom.xml 9e06e89 > tools/pom.xml 114ba8e > tools/src/main/java/org/apache/oozie/tools/OozieDBCLI.java 8b3e939 > tools/src/main/java/org/apache/oozie/tools/OozieDBExportCLI.java > PRE-CREATION > tools/src/main/java/org/apache/oozie/tools/OozieDBImportCLI.java > PRE-CREATION > tools/src/test/java/org/apache/oozie/tools/TestDBLoadDump.java PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_ac.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_bna.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_bnj.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_ca.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_cj.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_slareg.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_slasum.json PRE-CREATION > tools/src/test/resources/dumpData/ooziedb_wf.json PRE-CREATION > > Diff: https://reviews.apache.org/r/51137/diff/ > > > Testing > ------- > > I've tested migrating between MySQL, Derby and Oracle. After restarting > Oozie, the workflows/coordinators kept running and their status was updated > properly. > > > Thanks, > > Peter Cseh > >
