ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

2007年~2011年ごろまで はてなダイアリー に書いてた記事を引っ越してきました。

ACLキャッシュ、諦めます。考え直し。

えっと、つまりですね。YB_LOGINED_UID(ログインしているユーザー全てを表す仮想ユーザー), YB_GUEST_ID(ログインしていないユーザー全てを表す仮想ユーザー), YB_ALL_UID (YB_LOGINED_UIDとYB_GUEST_UIDの和。つまりybにアクセスしてくる全ユーザー)に関する権限リスト展開が、むちゃくちゃややこしくかつ考慮すべき事も山積みのようなのです。

たとえばYB_LOGINED_UIDと、新しく登録されるユーザーの関係とか、YB_ALL_UIDとYB_LOGINED_UID, YB_GUEST_UIDの優先順位の関係とか、とにかく、キャッシュとして・・・といいますか、「ユーザーIDから引っ張るためのキャッシュ」構築としては、どうにもまとまらない。これは不味い。

で、結論として。
ユーザーIDからACLを引っ張るためのキャッシュは、恒常的には保持しません。
ユーザーがシステムにログインした都度、構築してセッションに保持します。

これにより、GroupやACLやUserのCRUD操作時に、ACLキャッシュを考慮する必要が無くなります。また処理内容としても、ログインしたユーザー一人に関して、ACLを順繰りに展開・評価していきますので、せいぜい、ACLの展開・評価結果をキャッシュしておく程度でかなり楽になるはずです。その展開・評価結果のキャッシュも、Group/Acl/UserのCRUDで一々再生成するほどでは無いでしょう。
というのも、一つのYakiBiki・・・パーティション、と呼びましょうか。ま、ようするに一つのgroup/acl/dataが保持される単位です。user.datは共用されるかもしれませんから。
とにかく、一つのYakiBikiの単位では、ACLの数は2桁を超えることは無いだろう、と予測されるからです。
現実問題としてmixiが数個の単位。まぁmixiでグループ利用していると若干増えるかもしれませんが。
YakiBikiの場合、当初が個人ベース、あるいは中小企業内・あるいは部課単位を想定していますので、50個を超えることもないと思います。
一般的な使用方法の予測として、多くて20個くらいじゃないかと予想しています。それ以上になるとACLが紛らわしくなって、どのACLがどう違うのか、このACLはどういったデータに使うべきなのかわからなくなると思うからです。

つまり、ログイン時にACL展開・評価を行いそれをキャッシュして持ち回るのは、十二分に実用ラインであるように思います。
・・・あるいは、セッション開始時で良いかもしれません。anonymousなuser_contextを生成するタイミングにおいては、GUEST_IDと仮置きして、展開・評価する。でないと、GUEST_IDに対するACL評価ができませんので。

で、A2Dはそのまま。コレがないと検索処理でのACL絞込ができないので。
ですので・・・U2AとG2Aが要らなくなりますね。これはもともとACLキャッシュを恒常的に維持するために導入したindexです。従って、session開始毎にACLを展開・評価する(あー、これ、キーがUIDになるから普通にキャッシュできるな)仕掛けになると、そもそもこれらを使用する意味が無くなります。

・・・まぁ、こちらの方式が上手くいったら、消しちゃっても良いかも。それまでは保険で残しとこう。

となると、やっぱり、ACLを展開・評価する専用のIFが必要になります。キャッシュは内部で二段階で保持されます。

  • I/F用のキャッシュ。UIDをキーにして、全てのACLを展開・評価した最終結果をキャッシュしておく。ログイン時の処理軽減が目的。
  • 内部で、個々のACLに対する展開キャッシュ。ACLのIDがキーになりそう。

つまり、ACLの権限リストを展開したキャッシュ(これは当然個々のACL毎に分かれる)と、それを評価した最終結果(UIDと権限をキーとする)のキャッシュの二段階に分かれます。

よし。これなら行けそうだ・・・!!