11 月 19 2010
[PHP] BC Math 的妙用
最近用 PHP 開發某個 service 介面,來貼個心得。
這個 service 介面允許呼叫者使用 HTTP POST 欄位與 JSON 兩種方式傳進變數,處理儲存在 MySQL 資料庫裡面的資料,並以 JSON 作為輸出資料的格式。
為了避免被鑽漏洞,以及排除錯誤的資料,這個系統必須檢查每一個傳進來的參數是否正確。
但某些資料表的 ROW_ID 是 unsigned BIGINT,我必須另外考慮 32-bit 與 64-bit 平台的差異。
因為 PHP 的 intval 有這段說明:
The maximum value depends on the system. 32 bit systems have a maximum signed integer range of -2147483648 to 2147483647. So for example on such a system, intval(‘1000000000000’) will return 2147483647. The maximum signed integer value for 64 bit systems is 9223372036854775807.
所以,PHP 的 intval 是不能用的。
於是,我就動起了 BC Math 的歪腦筋。
由於 SQL statement 是字串,我不需要顧慮變數型態,可以直接把原本檢查 ROW_ID 的這段 code:
$Id = intval( $Input['id'] ); if ( empty($Id) ) { // Output error message exit(); }
改成這樣:
$Id = bcadd( "{$Input['id']}", "0" ); if ( empty($Id) ) { // Output error message exit(); }
PS 1. 傳入負值不用管,因為 ROW_ID 已經 unsigned 了,不會有影響。
PS 2. ROW_ID 的輸出也可以不用管,因為 query 出來的資料型態都是 string。
10 月 28 2011
Subversion 1.7
好一陣子沒寫 Blog 文章了… :oops:
剛好最近在 Subversion 遇到了些問題,就拿這話題來寫一下。
不可否認,Git、Mercurial 這類 DVCS 很棒,但我工作的環境一直用的是 Subversion,所以,我還是丟不下它。
從 server 端看,Subversion 1.6 -> 1.7 可以說是無痛移轉;但從 client 端看,影響不可謂不大。
首先,最大的差異是 metadata 的目錄與檔案結構變更(就是 .svn 目錄裡面的東西)。
下面這張圖是 Subversion 1.6.x 的 metadata 結構:
下面這張則是 1.7 的:
而這兩個版本的 working copy 無法相容。
舉例來說,當 TortoiseSVN 1.7.x 遇到原本使用 TortoiseSVN 1.6.x 維護的 working copy,軟體會要求 user 做轉換/升級;而 TortoiseSVN 1.6.x 無法解析轉換/升級後的 working copy。
(在 *NIX 系統裡,轉換/升級的指令是 svn upgrade )
另外,在 1.7 以前的結構,若是 working copy 存在著子目錄,每個子目錄下都會被放置 metadata(都會有 .svn 目錄);轉換/升級(至 1.7 )之後,metadata 只會被存放在 working copy 的根目錄下。
根據 release notes 的說法,這種儲存方式佔用的磁碟空間會比較小。但就我看來,只有在 working copy 的容量大到一定程度時,這種儲存方式才會佔用比較小的儲存容量,反之則否。另一方面,我沒有進行測試,但我相信對 client 而言(尤其是 Windows-based client),這種儲存方式會提昇 working copy 的存取速度。
其次,client 端多了個 svnrdump 可以用。
以往我們只能在 server 端作的 svnadmin dump 與 svnadmin load,如今在 working copy 也可以做 svnrdump dump 與 svnrdump load 。
除了這兩個(我覺得)比較大的變動,其他如 svn patch、svn relocate 等等的指令,也被引入了。
有興趣的可以看看 release notes。
By Joe Horn • Programing 1 • Tags: Subversion, SVN, TortoiseSVN, upgrade