資訊專(zhuān)欄INFORMATION COLUMN
大家好，去年5月份開(kāi)始到今年2月份，我們一共割接了40多套PG，今天就來(lái)聊一聊遇到的那些遷移和使用的“坑”。
希望這是一期不錯(cuò)的節(jié)目。
坑主駕到（一）
開(kāi)發(fā)用to_date()的一定要注意，有可能查詢(xún)不出數(shù)據(jù)，wrongresult
查詢(xún)結(jié)果不一致。Oracle能查出數(shù)據(jù)，PG查出來(lái)數(shù)據(jù)為空。先來(lái)看看具體的截圖：
其實(shí)這原本是一個(gè)上百行的SQL，問(wèn)題發(fā)生在此處定位需要不停的拆分和測(cè)試，我略微精簡(jiǎn)了一下。我們調(diào)整后的SQL如下。
會(huì)發(fā)現(xiàn)數(shù)據(jù)立馬有了。
其實(shí)這個(gè)問(wèn)題很簡(jiǎn)單，Oracle使用的date類(lèi)型是帶時(shí)分秒的，而Postgresql的date類(lèi)型是不帶時(shí)分秒的。所以在Oracle遷移到PostgreSQL，轉(zhuǎn)換的時(shí)候都會(huì)把Date類(lèi)型改造成Timestamp類(lèi)型。
問(wèn)題就在于PostgreSQL自帶了to_date函數(shù)。該函數(shù)的返回類(lèi)型是PostgreSQL中的Date類(lèi)型。
所以在上面就相當(dāng)于數(shù)據(jù)類(lèi)型不一致，導(dǎo)致查不到數(shù)據(jù)。該問(wèn)題解決辦法有兩種：
坑主駕到（二）
序列順序問(wèn)題
這個(gè)問(wèn)題是我們創(chuàng)建了序列，開(kāi)發(fā)使用的時(shí)候發(fā)現(xiàn)序列產(chǎn)生的值居然比當(dāng)前序列最大值還要小。
這個(gè)問(wèn)題的主要原因就是Oracle和PostgreSQL在序列上有差異，我們主要來(lái)觀察一下PG的行為：
1、先創(chuàng)建一個(gè)序列，起使值100，cache值20，會(huì)話(huà)A讀一下nextval。
2、接下類(lèi)在開(kāi)會(huì)話(huà)B，讀一下nextval，發(fā)現(xiàn)值變成了120。
注意按照Oracle數(shù)據(jù)庫(kù)的邏輯，此時(shí)序列的最大值已經(jīng)是120了。
3、返回到會(huì)話(huà)A，再次獲取nextval，發(fā)現(xiàn)值是101。
此時(shí)就出現(xiàn)了開(kāi)發(fā)遇到的情況：序列產(chǎn)生的值居然比當(dāng)前序列最大值還要小。
大多數(shù)序列只要不存在時(shí)間依賴(lài)關(guān)系，使用上都沒(méi)問(wèn)題。但是如果出現(xiàn)了數(shù)字小的序列一定要比數(shù)字大的序列時(shí)間早這種邏輯，就需要把序列的cache值設(shè)置成1。
坑主駕到（三）
substr函數(shù)結(jié)果不一致
PostgreSQL
Oracle
Substr函數(shù)的起使位置要從1開(kāi)始，如果位置從0開(kāi)始，雖然有數(shù)據(jù)但是和Oracle不一致。
坑主駕到（四）
事務(wù)問(wèn)題
這個(gè)問(wèn)題我對(duì)Oracle、MySQL、PostgreSQL做了詳盡的測(cè)試，結(jié)論就是
在Oracle和MySQL中，當(dāng)其他會(huì)話(huà)更新或刪除了選定的行時(shí)，當(dāng)前會(huì)話(huà)在執(zhí)行事務(wù)之前將重新檢查最新的數(shù)據(jù)。PostgreSQL當(dāng)選定的行被其他會(huì)話(huà)更新或刪除時(shí)，當(dāng)前會(huì)話(huà)將忽略這些行。
事務(wù)問(wèn)題會(huì)導(dǎo)致出現(xiàn)數(shù)據(jù)刪除丟失。需要應(yīng)用程序側(cè)考慮這個(gè)問(wèn)題進(jìn)行改造。
由于篇幅的原因，今天的“入坑到出坑”娛樂(lè)節(jié)目，暫時(shí)介紹到這里。文中如有錯(cuò)誤，請(qǐng)大神們幫忙把“坑”填了。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/129996.html
摘要：順便補(bǔ)充一句，微信官方提供的判斷依舊不全面，最新出來(lái)的蘋(píng)果手機(jī)還沒(méi)有完全支持相關(guān)的坑可以在官方社區(qū)的問(wèn)答中找到。 首次在這里寫(xiě)點(diǎn)東西，還請(qǐng)各位大佬擔(dān)待點(diǎn)。 摘要：昨天的placeholder-class只是希望各位看官注意，而今天的textarea就絕對(duì)是一個(gè)超級(jí)大坑！而且如果看官手中沒(méi)有蘋(píng)果手機(jī)測(cè)試的話(huà)，這個(gè)可就真的是個(gè)坑了！為啥？難道要等到用戶(hù)向你反饋你們產(chǎn)品有bug？？？.......
摘要：今年歲，目前在某行業(yè)頭部企業(yè)任職測(cè)試負(fù)責(zé)人，管理人的測(cè)試團(tuán)隊(duì)。渾渾噩噩的年我年出生，年二本畢業(yè)，專(zhuān)業(yè)是電子信息工程專(zhuān)業(yè)。轉(zhuǎn)行這年截止此時(shí)此刻，我已入坑近年時(shí)間，經(jīng)歷家互聯(lián)網(wǎng)公司，最近一份工作已有年之多，目前任職測(cè)試負(fù)責(zé)人。 ...
摘要：近期在做微信支付那方面的工作由于要在之前開(kāi)發(fā)人員的基礎(chǔ)上進(jìn)行開(kāi)發(fā)其中使用到了這個(gè)第方支付的。下面梳理下正常開(kāi)發(fā)的流程請(qǐng)點(diǎn)擊下面的鏈接付款。結(jié)果總是提示必須是組鍵值對(duì)。主要是官方?jīng)]有提供明確的請(qǐng)求頭信息給我們導(dǎo)致我們一直在兜圈。 近期在做微信支付那方面的工作,由于要在之前開(kāi)發(fā)人員的基礎(chǔ)上進(jìn)行開(kāi)發(fā),其中使用到了ping++這個(gè)第3方支付的SDK。不得不說(shuō),ping++的SDK做的挺簡(jiǎn)單的,...
摘要：近期在做微信支付那方面的工作由于要在之前開(kāi)發(fā)人員的基礎(chǔ)上進(jìn)行開(kāi)發(fā)其中使用到了這個(gè)第方支付的。下面梳理下正常開(kāi)發(fā)的流程請(qǐng)點(diǎn)擊下面的鏈接付款。結(jié)果總是提示必須是組鍵值對(duì)。主要是官方?jīng)]有提供明確的請(qǐng)求頭信息給我們導(dǎo)致我們一直在兜圈。 近期在做微信支付那方面的工作,由于要在之前開(kāi)發(fā)人員的基礎(chǔ)上進(jìn)行開(kāi)發(fā),其中使用到了ping++這個(gè)第3方支付的SDK。不得不說(shuō),ping++的SDK做的挺簡(jiǎn)單的,...
摘要：今天遇到一個(gè)一直認(rèn)為很簡(jiǎn)單的問(wèn)題，真正接手后才知道這么可怕大體是這樣的，默認(rèn)動(dòng)態(tài)加載的應(yīng)該是自動(dòng)向下，當(dāng)遇到頁(yè)面最下面應(yīng)該自動(dòng)向上渲染。動(dòng)態(tài)生成的都是根據(jù)來(lái)監(jiān)聽(tīng)獲取元素的信息。 今天遇到一個(gè)一直認(rèn)為很簡(jiǎn)單的問(wèn)題，真正接手后才知道這么可怕 大體是這樣的，默認(rèn)動(dòng)態(tài)加載的card應(yīng)該是自動(dòng)向下，當(dāng)card遇到頁(yè)面最下面應(yīng)該自動(dòng)向上渲染。showImg(https://segmentfault...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
