1 Reply Latest reply on Mar 2, 2013 8:27 AM by Bartosz Majsak

    [ARQ-PERSISTENCE] data cleanup questions

    Noah White Newbie

      I am using Alpha5 and have a couple of questions regarding the cleanup procedure. I'm using the default STRICT cleanup mode and in my arq XML my dataseed stragety is set to CLEAN_INSERT, though I think this is the default and therefore unncessary to specify this.

       

      My test class specifies @ApplyScriptAfter which is a sql file that resets a list of sequence tables. The test class also specifies @UsingDataSet which is a YAML file with a set of tables and row data.

       

      In this configuration by default the DB tables referenced in the YAML file should be automatically cleaned.  However, my test also inserts data into tables not referenced in the YAML file and since its not possbile to specify an empty table in a YAML file I can not include them there. Tables not referenced in the YAML file will not be cleaned so in order to clean up data in those tables my test method specifies a @CleanupUsingScript which takes care of that.

       

      What I am seeing is that when a test method specifies a @CleanupUsingScript it will no longer automatically clean up the tables/data defined in the @UsingDataSet and will only execute the SQL statements in the @CleanupUsingScript file.  I was surprised it didn't first do the automatic cleanup and then execute the cleanup script.  Is this a bug or a feature? If it's a feature I'd like to request that there's an option to behave the other way as that will save on the amount of SQL I need to provide by hand.

       

      My second question has to do with CLEAN_INSERT. I have a couple of test methods which use data sets for the same table. When the above mentioned cleanup happens and I don't specify truncating the common table in the @CleanupUsingScript (because I'd expected it to be cleaned as part of the default cleanup) and the second test method executes I see it fail to insert its YAML defined data set into that common table because the data from the other method is still there. The exception occurs in DBUnitDataHandler.prepare when it calls fillDatabase().  I'm surprised by this because I thought INSERT_CLEAN would delete data from this table as it is specified in the test methods YAML dataset. The arq persistence manual [1] says, CLEAN_INSERT: "Performs insert of the data defined in provided data sets, after removal of all data present in the tables referred in provided files.".  However, this is not happening as I see the data from the previous test method is still there at this time. Does this mean that the statement I have highlighted in bold referrs to the removal (and provided files) of the previous test method vs. the provided files of the test method being executed?

       

      -Noah

       

      [1] - https://docs.jboss.org/author/display/ARQ/Persistence

        • 1. Re: [ARQ-PERSISTENCE] data cleanup questions
          Bartosz Majsak Master

          Hi Noah.

           

          I am using Alpha5 and have a couple of questions regarding the cleanup procedure. I'm using the default STRICT cleanup mode and in my arq XML my dataseed stragety is set to CLEAN_INSERT, though I think this is the default and therefore unncessary to specify this.

           

          That's correct, STRICT cleanup mode is the default, but default seeding strategy is INSERT.

           

          .

          In this configuration by default the DB tables referenced in the YAML file should be automatically cleaned.  However, my test also inserts data into tables not referenced in the YAML file and since its not possbile to specify an empty table in a YAML file I can not include them there. Tables not referenced in the YAML file will not be cleaned so in order to clean up data in those tables my test method specifies a @CleanupUsingScript which takes care of that.

           

          What I am seeing is that when a test method specifies a @CleanupUsingScript it will no longer automatically clean up the tables/data defined in the @UsingDataSet and will only execute the SQL statements in the @CleanupUsingScript file.  I was surprised it didn't first do the automatic cleanup and then execute the cleanup script.  Is this a bug or a feature? If it's a feature I'd like to request that there's an option to behave the other way as that will save on the amount of SQL I need to provide by hand.

           

          That was somehow intended - they are mutually exclusive. However you are very right that it's not really a nicest feature. Please fill in feature request in JIRA if you can and I will take care of it.

           

           

          My second question has to do with CLEAN_INSERT. I have a couple of test methods which use data sets for the same table. When the above mentioned cleanup happens and I don't specify truncating the common table in the @CleanupUsingScript (because I'd expected it to be cleaned as part of the default cleanup) and the second test method executes I see it fail to insert its YAML defined data set into that common table because the data from the other method is still there. The exception occurs in DBUnitDataHandler.prepare when it calls fillDatabase().  I'm surprised by this because I thought INSERT_CLEAN would delete data from this table as it is specified in the test methods YAML dataset. The arq persistence manual [1] says, CLEAN_INSERT: "Performs insert of the data defined in provided data sets, after removal of all data present in the tables referred in provided files.".  However, this is not happening as I see the data from the previous test method is still there at this time. Does this mean that the statement I have highlighted in bold referrs to the removal (and provided files) of the previous test method vs. the provided files of the test method being executed?

           

          This is a misleading documentation. From the DBUnit perspective CLEAN_INSERT is a combination of DELETA_ALL and INSERT operations, so it deletes the whole table content upfront. But apparently the behaviour you are facing is not correct. I assume you are using CLEAN_INSERT explicitly, right? Would it be possible to provide test case which leads to this problem so I can reproduce and analyze what kind of mess is going on there?

           

          Many thanks for the such a detailed feedback.