Neil's Note

Virtual Columns in InnoDB INFORMATION_SCHEMA 記錄了一些關於 InnoDB 管理的 schema 物件的 metadata, 這些資訊來自於 InnoDB 內部 system tables, 這些資訊沒辦法跟一般 table 一樣, 可以直接查詢, 傳統上的做法應該是解析 SHOW_ENGINE_INNODB_STATUS 的輸出. 不過 INFORMATION_SCHEMA 這張表有提供介面可以讓你使用 SQL 查詢這類型的資料. 這個跟 Virtual Column 有什麼關係?  Virtual Column 其實並不會儲存實體資料在 table 的 clustered index 內! 不過 Virtual Column 的 metadata 會存在 InnoDB 的 INFORMATION_SCHEMA  的 SYS_COLUMNS 內！ 舉例來說 ## 建立一張表 t 有著 a, b, c 三個欄位, c 是 virtual column CREATE TABLE t (a INT, b INT, c INT GENERATED ALWAYS AS(a+b), PRIMARY KEY(a)); ## SELECT * FROM t; +----+------+------+ | a | b | c | +----+------+------+ | 11 | 3 | 14 | +----+------+------+ ## 從 SYS_COLUMNS 中觀察 SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_COLUMNS WHERE TABLE_ID IN ( SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE "t%" ); +----------+------+-------+-------+--------+-----+ | TABLE_ID | NAME | POS | MTYPE | PRTYPE | LEN | +----------+------+-------+-------+--------+...

關於 CORS 最簡單的理解大概是在 A 網域的頁面呼叫了 B 網域的資源 時，會發出的跨網域請求。只要是不同的 網域 、 PORT 、 通訊協定 ，通通都算跨網域。 基於安全性考量，程式碼所發出的跨網域 HTTP 請求 (XMLHttpRequest, Fetch)，一樣也會受到 same origin policy 的限制，必須在同個網域內，否則一樣使用 CORS 的請求。 會需要注意 CORS 的 Request: XMLHttpRequest, Fetch 網頁字體 (跨網域的 css 裡面的 @font-face) WebGL 的 texture drawImage 用到的圖片 or video frames css 這裡就不多寫關於 Simple Request 與 Preflighted requests，可以直接參考 MDN  的網站。 不過當遇到 Preflighted Request 的時候有些要注意的事情。 WebKit Nightly 與 Safari Technology Preview 對 Accept、Accept-Language (en-US) 及 Content-Language (en-US) 標頭值加入了額外的限制。假如這三個 header 中有任一個擁有「非標準」值，WebKit／Safari 就不會將該請求視為 Simple Request header('Content-Type: application/json; charset=utf-8'); header('Access-Control-Allow-Origin: http://abc.com'); header('Access-Control-Allow-Methods: POST, GET, DELETE, PUT, PATCH, OPTIONS'); header('Access-Control-Max-Age: 86400'); header("Access-Control-Allow-Headers: Content-Type, Accept"); 以上述來說, 如果只想允許 http://abc.com 的網域過來的請求， 就在 Access-Control-Allo...

DNS 階層 DNS 並不是單一伺服器，而是整個基礎架構，由一堆 name servers 在不同的階層中 在 DNS 階層中，主要有分成四個類型的伺服器類型 DNS Resolver (Recursive Resolver): 作用是接收如網頁瀏覽器、應用程式等的查詢，並將請求轉發給其他 DNS name servers Root-level name servers: 維護 top-level domain, ex:    .com  ,    .edu  ,    .us  ,  .io  等等。舉例來說，當你查詢 maper.io 的 IP 時，root-level name servers 會回傳一個擁有 .io 的 top-level domain name server 的 IP 地址列表給你。更簡單來說，root-level name servers 會告訴你 .io 要去哪個 top-level domain name server 中找，有點像是索引的概念。 Top-level domain name servers: 這些伺服器有著 authoritative name servers 的 ip。 Authoritative name servers: Authoritative name servers 是 name servers 查詢中的最後一站。如果 Authoritative name servers 能夠存取請求的記錄，則其會將已請求主機名稱的 IP 位址傳回到發出初始請求的 DNS 解析程式，也就是回傳網頁/應用程式的主機 ip。 Iterative vs recursive query resolution 有兩個執行 DNS query 的方式 Iterative: 本地端向本地/ISP, root, top-level domain, authoritative name servers 依序請求 ip 位置。 Recursive: 本地 -> root -> top-level-domain -> authoritative -> top-level-domain -> ...