幹壞事是進步最大的原動力
忘了在哪邊看到的，好像是 Twitter 上看到的，mnot 與 phk 兩個人弄了一個新的 RFC 標準，可以在 HTTP header 裡面傳結構性資料：「Structured Field Values for HTTP」。
第一個最直接的問題就在「A.1. Why Not JSON?」這個章節說明，考慮了既有的限制，包括 JSON spec，以及市場上既有的 JSON library 的實做。
但也因為自己定義了資料結構，Serializing & Parsing 就得另外再開發 library 處理，這樣會有多少 framework 支援就是個問題了，而且對於開發者來說，直接塞 JSON 很好理解，這個標準的前景不知道會怎麼樣...
在「Yubico iOS Authentication Expands to Include NFC」這邊看到 iOS 13 上對於 NFC 類的 MFA 會有的進展。
主要是因為之前的 NFC 只有讀取能力，所以 U2F/FIDO2/WebAuthn 之類的應用沒有辦法套用上去：
Previously, NFC on iOS was read-only, which meant that it couldn’t support modern authentication protocols like FIDO U2F, FIDO2/WebAuthn that require both read and write capabilities – but now that has changed.
iOS 13 後開放了 API 可以讀寫，所以有辦法支援這些協定了：
With these recent updates, iPhone users (running iOS 13+) can experience mobile NFC authentication with a YubiKey 5 NFC or Security Key NFC by Yubico on apps and browsers that have added support.
對於主力放在 Apple Ecosystem 的人，總算是等到了...
就如同上一篇提到的，Trac 在 1.1.1 後新增了 time 格式，所以本來的 DateFieldPlugin 有些資料要轉換。我這邊只有用在 Due Date，所以就是轉 due_date 的資料而已。
先把 due_date 都改成 due_date_bak：
UPDATE ticket_custom SET name = 'due_date_bak' WHERE name = 'due_date';
然後重新計算資料，這邊是因為所有的系統都是 UTC，所以直接轉就可以了：
INSERT INTO ticket_custom (ticket, name, value) SELECT ticket, 'due_date', LPAD(UNIX_TIMESTAMP(STR_TO_DATE(value, '%Y-%m-%d')) * 1000000, 18, '0') FROM ticket_custom WHERE name = 'due_date_bak';
而我的 Report 有用到 due_date 欄位的東西，本來是 c.value 直接輸出，現在要改成：
FROM_UNIXTIME(CONVERT(c.value / 1000000, UNSIGNED INTEGER), '%Y-%m-%d') AS due_date
Trac 1.2 相較於 1.0 最不習慣的地方應該是修改界面的位置改變了，現在 Add Comment 變成在 Modify 下面，有點不太習慣，但之後用久了應該就會習慣了。其他的修一修改一改都會動了...
Trac 的版本玩法跟早期 Linux Kernel 的模式有點像，也就是版號偶數是正式版，奇數是開發版... 雖然現在 Linux Kernel 已經不玩這套了，但 Trac 還是維持這樣的開發方式。
先前一直都是用 Trac 1.0，其中 Due Date 的功能則是用「DateFieldPlugin」這個套件，讓 Trac 支援 date 格式，於是就可以在 [ticket-custom] 裡面指定 Due Date 了：
due_date = text due_date.date = true due_date.date_empty = false due_date.label = Due Date due_date.value = <now>
在套件的頁面也有提到在 Trac 1.1.1 後就有內建的方式可以用了：
Notice: This plugin is deprecated in Trac 1.2 and later. Custom fields of type time were added in Trac 1.1.1.
連結是連到 1.1 的，我要測 1.2 的，所以往現在的版本翻資料，可以看到在 TracTicketsCustomFields 這邊的說明：(這邊就懶的照原來 html 排了，用 pre 直接放縮排)
time: Date and time picker. (Since 1.1.1.)
label: Descriptive label.
value: Default date.
order: Sort order placement.
format: One of:
relative for relative dates.
date for absolute dates.
datetime for absolute date and time values.
這樣一來設定就會變成：
due_date = time due_date.format = date due_date.label = Due Date due_date.value = now
但底層資料怎麼存？先看 ticket_custom 這個表格的結構，可以看到是 EAV 的架構：
+--------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+------------+------+-----+---------+-------+ | ticket | int(11) | NO | PRI | NULL | | | name | mediumtext | NO | PRI | NULL | | | value | mediumtext | YES | | NULL | | +--------+------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
隨便拉一些可以看出來放法很簡單：
+--------+----------+------------+ | ticket | name | value | +--------+----------+------------+ | 1 | due_date | 2016-10-03 | +--------+----------+------------+
改成 Trac 1.2 內建的 time 後，塞 2018/02/28 變成：
+--------+----------+--------------------+ | ticket | name | value | +--------+----------+--------------------+ | 1 | due_date | 001519776000000000 | +--------+----------+--------------------+
拿掉後面的六個 0 後可以看到就是 2018/02/28 了，要注意的是，這邊會受到時區影響，我一開始測試的時候沒調整，寫進去的時間是用伺服器預設的時區計算的。另外也大概能理解前面放兩個 0 的目的，是為了讓 string 比較時的大小就會是數字實際的大小。
$ date --date=@1519776000 Wed Feb 28 00:00:00 UTC 2018
這樣就知道要怎麼做人工轉換了...
這邊的 BLOB field 指的包括 VARCHAR、VARBINARY、BLOB、TEXT 這些常常被拿來放大物件的類型：「Externally Stored Fields in InnoDB」。
這跟 InnoDB 存放的格式 (ROW_FORMAT) 也有關，對於不同的格式都需要分開討論。
看之前需要帶一些背景知識，像是 Database index 裡面講到 index 種類時所提到的 Clustered。
看完後對 MySQL InnoDB 的運作方式會更了解一些，對於規劃 schema 也加減有些幫助。