DataSet導(dǎo)入三個坑

1外鍵

本小節(jié)從數(shù)據(jù)庫實際使用的視角乘寒，給出了在各種場景下的解決方案望众。對工具提供的功能進行一個綜合使用匪补。
外鍵是一個常見的保證數(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表中使用了這兩個表中的主鍵作為外鍵，表達用戶粉與被粉的關(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)入的問題之外，另外一種常見的問題是主鍵沖突瓶盛，或者更確切一點說是某個帶有自增ID序列帶來的沖突最欠。如果在數(shù)據(jù)庫中插入該表的記錄，則新插入的值不能和已有的值重復(fù)惩猫，而且必須大于其中最大的一個值窒所。一般通過程序?qū)懭霐?shù)據(jù)庫記錄大多是新增記錄的場景，不指定該列的值帆锋，只將其他列的值插入吵取，讓ID按照自增規(guī)則由數(shù)據(jù)庫自行填寫的方式進行。而在通過數(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策略進行導(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)容進行修改上述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操作提供的重置序列的功能，強制重新初始化杂抽，進而保證了數(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ù)庫中最容易讓程序員踩坑的問題如果進行一個排名痕檬，估計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)入進數(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文件格式進行導(dǎo)入
新的數(shù)據(jù)類型規(guī)避了上述DBUnit的缺陷，因此不會再發(fā)生整列數(shù)據(jù)丟失的問題了惶洲。這也是筆者喜歡DBRier的原因之一按声。
還有什么樣的數(shù)據(jù)導(dǎo)入導(dǎo)出的坑呢？歡迎與筆者討論恬吕。