1外鍵

本小節(jié)從數(shù)據(jù)庫實際使用的視角，給出了在各種場景下的解決方案。對工具提供的功能進(jìn)行一個綜合使用。
外鍵是一個常見的保證數(shù)據(jù)庫內(nèi)容完整性的一種方式。當(dāng)然現(xiàn)在出于性能考慮，在互聯(lián)網(wǎng)企業(yè)中比較少甚至禁止使用外鍵。在DBRider中，提供了以下的與外鍵相關(guān)的功能
1）@DataSet注解中的disableConstraints屬性
這個屬性如果為true,則可以暫時去除外鍵約束，以便于數(shù)據(jù)導(dǎo)入操作。

@DataSet(value ="users.yml", strategy = SeedStrategy.UPDATE,
       disableConstraints = true,cleanAfter = true,transactional = true)
public void shouldLoadDataSetConfigFromAnnotation(){

 }

2）@ExportedDataSet導(dǎo)出時一并導(dǎo)出關(guān)聯(lián)表
在導(dǎo)入某個數(shù)據(jù)庫表的數(shù)據(jù)時，如果存在外鍵的話，經(jīng)常會發(fā)生因為外鍵不存在導(dǎo)致的數(shù)據(jù)無法導(dǎo)入的問題。為了預(yù)防此類事件的發(fā)生，一個好的措施是在導(dǎo)出目標(biāo)表時將依賴數(shù)據(jù)表一并導(dǎo)出。DBRider在@ExportDataSet中通過dependentTables提供了該功能。如下例，

@Test
@DataSet("datasets/yml/users.yml")
@ExportDataSet(format = DataSetFormat.YML, includeTables = {"USER"}, dependentTables = true, outputName = "target/exported/yml/dependentTables.yml")
public void shouldExportYMLDataSetUsingIncludesWithDependentTables() {
}

只要簡單地將dependentTables設(shè)置為 true，就可以實現(xiàn)上述需求。雖然只是導(dǎo)出USER表，但是TWEET和FOLLOWER兩個表也被導(dǎo)出了。因為USER表中使用了這兩個表中的主鍵作為外鍵，表達(dá)用戶粉與被粉的關(guān)系。

<?xml version='1.0' encoding='UTF-8'?>
<dataset>
  <TWEET ID="abcdef12345" CONTENT="dbunit rules!" DATE="2020-10-02 17:07:52.0" USER_ID="1"/>
  <USER ID="1" NAME="@realpestano"/>
  <USER ID="2" NAME="@dbunit"/>
  <FOLLOWER ID="1" USER_ID="1" FOLLOWER_ID="2"/>
</dataset>

自增序列與ID主鍵沖突

在往數(shù)據(jù)庫中導(dǎo)入數(shù)據(jù)時，除了因為外鍵約束不滿足導(dǎo)致無法導(dǎo)入的問題之外，另外一種常見的問題是主鍵沖突，或者更確切一點(diǎn)說是某個帶有自增ID序列帶來的沖突。如果在數(shù)據(jù)庫中插入該表的記錄，則新插入的值不能和已有的值重復(fù)，而且必須大于其中最大的一個值。一般通過程序?qū)懭霐?shù)據(jù)庫記錄大多是新增記錄的場景，不指定該列的值，只將其他列的值插入，讓ID按照自增規(guī)則由數(shù)據(jù)庫自行填寫的方式進(jìn)行。而在通過數(shù)據(jù)庫導(dǎo)入時，屬于控制數(shù)據(jù)庫上下文的場景。往往就會產(chǎn)生沖突，
1）導(dǎo)入記錄中需指定自增ID的主鍵值，以保證被導(dǎo)入數(shù)據(jù)的完整性。
2）待導(dǎo)入的數(shù)據(jù)源自數(shù)據(jù)庫之前的某一次導(dǎo)出的數(shù)據(jù)集。隨后數(shù)據(jù)庫經(jīng)歷了反復(fù)插入刪除等操作后，自增主鍵值已經(jīng)向后偏移。例如針對某個場景有多個測試用例需要導(dǎo)入數(shù)據(jù)導(dǎo)同一個表。后續(xù)用例的執(zhí)行上下文于是受到了前面執(zhí)行用例的影響。
3）導(dǎo)入時通過默認(rèn)的CLEAN_INSERT策略進(jìn)行導(dǎo)入，雖然刪除了原先存在的數(shù)據(jù)，但是數(shù)據(jù)庫的自增主鍵值并沒有回退，這樣就導(dǎo)致導(dǎo)入記錄時報主鍵沖突。
那是否可以通過采用INSERT/UPDATE的策略呢？之前在介紹各種導(dǎo)入策略時有提及，只INSERT而不是先刪除再導(dǎo)入時，會存在數(shù)據(jù)記錄重復(fù)無法導(dǎo)入的問題，而在這個場景下，因為主鍵沖突帶來的問題還是沒有解決。那是否可以使用UPDATE策略來更新各個記錄的主鍵ID呢？考慮到一般采用主鍵ID的是記錄類數(shù)據(jù)的場景，無法保證原記錄的存在，所以也不太適合使用UPDATE的策略。
從上述問題描述中，讀者也理解到了問題產(chǎn)生的原因并不在主鍵ID和記錄自身，而是因為在原數(shù)據(jù)集導(dǎo)出后，在保持?jǐn)?shù)據(jù)不變的情況下，數(shù)據(jù)庫中該表經(jīng)歷了插入和刪除后，自增序列已經(jīng)向后偏移。
于是，只要保證自增序列ID的值小于待插入數(shù)據(jù)的值，該問題就能規(guī)避掉了。利用@DataSet的伴隨操作就可以了
解決辦法1：利用executeStatementsBefore 重置自增序列
@Test
@DataSet(value = "datasets/yml/users.yml",
executeStatementsBefore = "alter table USER auto_increment = 100;")
public void shouldSeedDataSetDisablingContraintsViaStatement() {
//......
}

通過重置該表的Sequence到一個小于待導(dǎo)入數(shù)據(jù)集中最小ID的值，再配合隨后的CLEAN_INSERT操作，就可以規(guī)避該問題了。當(dāng)然這個操作需要在準(zhǔn)備好數(shù)據(jù)集后，根據(jù)具體內(nèi)容進(jìn)行修改上述executeStatementsBefore 。因為很有可能待導(dǎo)入數(shù)據(jù)源自某一份導(dǎo)出數(shù)據(jù)，根據(jù)測試用例需求稍加修改而來，因此該部分修改也具備一定的通用性，工作量可控。
另外，上述示例代碼是MYSQL語法，如果目標(biāo)數(shù)據(jù)庫是ORACLE,重置Sequence的寫法略有差別。
解決辦法2： 利用TRUNCATE_INSERT的SeedStrategy
通過源碼分析，可以了解到DBRider還額外提供了TRUNCATE_INSERT的操作，雖然該功能未在其官方文檔中說明，但是也可以直接使用。

public enum SeedStrategy {
    CLEAN_INSERT(DatabaseOperation.CLEAN_INSERT),
    TRUNCATE_INSERT(new CompositeOperation(DatabaseOperation.TRUNCATE_TABLE, DatabaseOperation.INSERT)),
    INSERT(DatabaseOperation.INSERT),
    REFRESH(DatabaseOperation.REFRESH),
    UPDATE(DatabaseOperation.UPDATE);
//......
}

利用TRUNCATE操作提供的重置序列的功能，強(qiáng)制重新初始化，進(jìn)而保證了數(shù)據(jù)導(dǎo)入時不再會發(fā)生自增主鍵沖突的問題。
當(dāng)然也可以參考被測系統(tǒng)向數(shù)據(jù)庫插入數(shù)據(jù)時不指定ID，而是由數(shù)據(jù)庫自行決定的方式，不過這個方案相比前面的來說略顯復(fù)雜，涉及到導(dǎo)出數(shù)據(jù)時剔除該列數(shù)據(jù)，工作量較大，不是很推薦。感興趣的讀者可以自行嘗試。

Null處理

數(shù)據(jù)庫中最容易讓程序員踩坑的問題如果進(jìn)行一個排名，估計Nullable會排在最前面。如果一個數(shù)據(jù)列是Nullable,在導(dǎo)入導(dǎo)出時會遇到不少問題。
首先DBRider 在使用JSON格式在導(dǎo)出null時，會在該條記錄的最后位置額外多一個逗號，導(dǎo)致導(dǎo)出內(nèi)容不符合JSON格式，需要手工修改。當(dāng)然，該問題在報告之后很快就被修復(fù)了。詳見fix bug with extra comma in json object #160，但似乎還是未解決，如果遇到，需要手工處理，或嘗試最新的DBRider版本。
其次是在數(shù)據(jù)導(dǎo)入時的問題，DBUnit一個著名的bug是在導(dǎo)入XML、CSV格式的文件時，如果待導(dǎo)入文件的第一條記錄的Nullable列的數(shù)據(jù)正好是Null，那么DBUnit會忽略該列，整列數(shù)據(jù)都會被丟失，即使后續(xù)數(shù)據(jù)記錄中該列不為Null，也會被忽略而不導(dǎo)入進(jìn)數(shù)據(jù)庫。
解決辦法1：調(diào)整數(shù)據(jù)行順序，讓第一條記錄包含不為Null
這樣做是最簡單的處理方式，正所謂將問題解決在發(fā)生前。不過數(shù)據(jù)文件較多時手工調(diào)整也比較麻煩，或者記錄順序調(diào)整會影響測試用例執(zhí)行結(jié)果時，這樣調(diào)整就會帶來麻煩了。
解決辦法2：XML導(dǎo)入時指定DTD
DBUnit給出的一個解決辦法是，在導(dǎo)出XML文件的同時，再導(dǎo)出一份XML_DTD，來指明數(shù)據(jù)庫的列。導(dǎo)入數(shù)據(jù)時，利用DTD來指定數(shù)據(jù)列，如下例：

<!--ELEMENT COMPANY EMPTY-->
<!--ATTLIST COMPANY
    ID CDATA #REQUIRED
    NAME CDATA #REQUIRED
    PARENT CDATA #IMPLIED
  -->
]>
<dataset>
  <company id="1" name="HQ"></company>
  <company id="2" name="spain hq" parent="1"></company>
  <company id="3" name="barcelona" parent="2"></company>
</dataset>

這樣就不會發(fā)生因為Null導(dǎo)致的數(shù)據(jù)列丟失問題了。
解決辦法3：利用DBRider提供的JSON/YAML文件格式進(jìn)行導(dǎo)入
新的數(shù)據(jù)類型規(guī)避了上述DBUnit的缺陷，因此不會再發(fā)生整列數(shù)據(jù)丟失的問題了。這也是筆者喜歡DBRier的原因之一。
還有什么樣的數(shù)據(jù)導(dǎo)入導(dǎo)出的坑呢？歡迎與筆者討論。