這兩天，被分配修改了幾個bug, 修改的過程比較有趣，所以總結出來。
一， 需要在原來的查詢的基礎上，再增加乙個查詢的條件，如按上級部門查詢
1. 修改html的頁面，在查詢欄，增加乙個錄入框
2. 修改頁面控制的js檔案
search : function()3. 修改queryaction中的setquerycondition私有方法，加入parentorg的條件
4. 修改userdao中的方法
原來的sql語句： stringbuilder hql = new stringbuilder("from user t where t.delflag=false");
分析sql之後，認為對於部門的查詢條件，少乙個部門的關聯表，對hibernate的hql的並不是非常熟，於是參考這個dao中，其它的查詢方法, 修改這個hql
stringbuilder hql = new stringbuilder("from centeruser t inner join t.parentorg o where t.delflag=false");
接著修改，引用hql的另乙個地方， 增加insert部分的**。
最後，從頁面開始除錯，增加的部門的查詢條件。
其實只是主線 mainline 增加了乙個條件 add condition 而已,不是extendline, 更不是inline
二， 有乙個資料查詢，有重複資料。
在後台找到這個sql, 感覺sql有問題，但是sql比較複雜。看了兩遍，始終不知道sql中什麼地方出錯。
後來，突然想起，系統中, 還有一處填報資料的翻頁功能，與它類似。馬上找到這個功能的sql, 把這個sql中的一部分，複製出來，對比之後找到了原因，原來資料查詢的sql中少了乙個條件。加上之後，除錯就可以通過了。
其實只是相同邏輯的對比而已
三， 還有乙個錯誤，在增加某條資料時，一直提示名稱重複。
檢查之後，在頁面的校驗中，從後台返回的資料格式，以及含義。沒有注意到，使得校驗條件通過。這段**是移植過來的。在這個過程中，沒有注意到客戶端和伺服器端傳遞的引數之間的差別，導致邏輯出錯。這也是我需要注意的地方。
這是一種習慣或者素質，需要在開發的過程中培養
業務邏輯處理
功能的實現，都是依靠業務邏輯來完成的，記得看過不能完成業務邏輯的程式設計師都不會成長的，確實是的，最近在完成業務邏輯的時候，程式的業務判斷有很多的，所以開始接觸，設計模式，看到來一些設計模式，看結合專案，確實是可以根據設計模式來改寫的，so，懂得設計模式可以快速的，寫好的 的。關於函式同步和非同步之...
業務邏輯漏洞
業務邏輯漏洞是一類特殊的安全漏洞，業務邏輯漏洞屬於設計漏洞而非實現漏洞，是業務邏輯設計不嚴謹導致的漏洞。大多數業務邏輯漏洞沒有明顯的攻擊特徵，難以通過漏洞掃瞄的方式發現，也難以通過安全裝置來防護。繞過驗證 主要指身份驗證體系設計存在缺陷，可以使用某些技術手段繞過驗證機制冒用他人身份。越權訪問 主要指...
OC OD 線或線與邏輯
一.什麼是oc od 集電極開路門 集電極開路 oc或源極開路od open drain是漏極開路輸出的意思，相當於集電極開路 open collector 輸出，即ttl中的集電極開路 oc 輸出。一般用於線或 線與，也有的用於電流驅動。open drain是對mos管而言，open collec...