Skip to content
  • Sebastien Ponce's avatar
    Redesign of the DB schema for the tape side allowing to drop the migHunter. · 5b172c43
    Sebastien Ponce authored
    The main gains are :
      - simpler DB schema : StreamToTapeCopy and SvcClass2TapePool have disappeared. TapeCopy is split in to the dedicated RecallJob and MigrationJob. Stream is replaced by MigrationMount that includes all data needed from the Tape table (so the Tape table only used by recall now).
      - simpler concepts : MigrationMounts match with mounts and do not survive them (as Stream did), MigrationRouting table explicitely gives the migration routing. NbDrives has moved to the TapePool
      - less components : migHunter is gone, replaced by the MigrationRouting table and by a DB job that starts the needed mounts
      - better error reporting : migration failures due to bad configuration are reported sunchronously to the user, on file close or even on file opening when possible. e.g. if the combination of svcClass and fileClass given by the the user is not present in the MigrationRouting table, the file opening will fail with message "File recreation canceled since the file cannot be routed to tape". This case used to loop forever in the migration part.
    
    Conflicts:
    
    	castor/db/oracleCommon.sql
    	castor/db/oracleSchema.sql
    	castor/db/oracleTapeGateway.sql
    	castor/tape/tapegateway/daemon/TapeStreamLinkerThread.cpp
    	castor/tape/tapegateway/daemon/VmgrTapeGatewayHelper.cpp
    	castor/tape/tapegateway/daemon/VmgrTapeGatewayHelper.hpp
    	castor/tape/tapegateway/daemon/ora/OraTapeGatewaySvc.cpp
    	castor/tape/tapegateway/daemon/ora/OraTapeGatewaySvc.hpp
    	codeGeneration/RH.xmi
    
    Conflicts:
    
    	castor/db/oracleCommon.sql
    5b172c43