nighty

    最近的二個(gè)項(xiàng)目，由于規(guī)模較小，都是十張表之內(nèi)，而且表關(guān)聯(lián)非常少。所以用了一下iBatis做為數(shù)據(jù)庫(kù)關(guān)系映射，本著減少手寫(xiě)JDBC代碼的目的，想著可以減少工作量。但是卻遇到了二個(gè)令人郁悶的問(wèn)題。由于環(huán)境的限制，使用了jdk1.4.x編譯的iBatis2.3版本，沒(méi)有使用最近的。

    第一問(wèn)題：  其中的一個(gè)項(xiàng)目，有一個(gè)表為它配置了sql Map的一個(gè)delete操作，非常簡(jiǎn)單，大概就是delete from xxx where id=#value#這樣的語(yǔ)句，然后用sqlMapClient進(jìn)行操作，日志打印完全正常，沒(méi)有報(bào)任何Exception，返回影響記錄數(shù)也是正確的。但是進(jìn)數(shù)據(jù)庫(kù)一看，巍然不動(dòng)！左查查，右查查，查不出任何毛病。更奇怪的是，數(shù)據(jù)庫(kù)表之間的所有關(guān)聯(lián)和索引全部取消，還是存在這問(wèn)題。其它的三個(gè)字段比較少的表，這樣配置，同樣的api調(diào)用卻正常！這個(gè)出問(wèn)題的數(shù)據(jù)庫(kù)表字段大概20+個(gè)左右。

    第二個(gè)問(wèn)題：另一個(gè)項(xiàng)目，是二期重構(gòu)，本來(lái)一期也不復(fù)雜，全部是使用JDBC實(shí)現(xiàn)的，只是有些表的字段太多，JDBC寫(xiě)到煩，特別是處理一些NULL的插入，還有批處理時(shí)異常日志的詳細(xì)處理也有點(diǎn)煩。近期做二期升級(jí)，就算采用iBatis來(lái)減少一些代碼量，于于喜涮涮地搞上去了，代碼的確減少了許多。單元測(cè)試也能通過(guò)，后來(lái)就設(shè)置了比較復(fù)雜的數(shù)據(jù)。發(fā)現(xiàn)問(wèn)題的現(xiàn)場(chǎng)如下：在一個(gè)業(yè)務(wù)接口中，一個(gè)事務(wù)中包含了許多SQL操作，有delete，也有insert，大概十個(gè)sql語(yǔ)句左右，全部放在一個(gè)batch中執(zhí)行，整個(gè)batch提交一個(gè)事務(wù)。測(cè)試環(huán)境提供了31個(gè)類(lèi)似的業(yè)務(wù)數(shù)據(jù)，總共執(zhí)行31個(gè)事務(wù)，采用for的循環(huán)執(zhí)行調(diào)用，每逢索引 i = 10*n  的時(shí)候就會(huì)卡住，這個(gè)操作得花很長(zhǎng)時(shí)間，最后能通過(guò)。后來(lái)進(jìn)行跟蹤，發(fā)現(xiàn)是在執(zhí)行第一個(gè)語(yǔ)句delete一個(gè)記錄（delete from xxx where id='xx'）同樣也是單表刪除。搜索了google，baidu，沒(méi)有任何資源，翻遍了文檔沒(méi)有任何說(shuō)明，查了網(wǎng)站FAQ也沒(méi)有辦法。于是，只能.......郁悶!

   為什么遇到delete都會(huì)有這個(gè)問(wèn)題？不曉得有沒(méi)有高手遇到同樣的問(wèn)題，這里算是總結(jié)的同時(shí)也提問(wèn)，希望有遇到相同類(lèi)型的高手給個(gè)解決的方案。如果不行，就得倒回去用JDBC實(shí)現(xiàn)，就此iBatis的體驗(yàn)使用也就擱置，估計(jì)以后也不會(huì)碰它了。Hibernate就不用了，有點(diǎn)小題大作。
   google了才知道，原來(lái)iBatis的書(shū)籍、論壇、資料、討論等等相比Hibernate要少很多。學(xué)習(xí)是很簡(jiǎn)單，但是遇到這種細(xì)節(jié)的時(shí)候，又不太愿意花時(shí)間去研究源代碼（都是現(xiàn)實(shí)所逼，有個(gè)球時(shí)間呀？）。所以選框架要慎重！！！

剛進(jìn)場(chǎng)的時(shí)候戲就落幕