BugTrack/2103
の編集
Top
/
BugTrack
/
2103
[
トップ
] [
編集
|
差分
|
履歴
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
*バックアップデータ構造の改善 [#pc299b0e] -ページ: [[BugTrack2]] -投稿者: [[Cue]] -優先順位: 低 -状態: 保留 -カテゴリー: 本体新機能 -投稿日: 2005-08-31 (水) 03:50:07 -バージョン: #contents **メッセージ [#v43ed818] **従来の仕様と特徴 (- PukiWiki 1.4.6) [#m5a5c2e9] ***バックアップファイル構造 [#i562cea6] +バックアップファイル1ファイルの中にそのページの全ての世代が保存されている ++ディスクスペースは少なくて良い(特に小さいページが沢山ある場合) +Boundaryは、PKWK_SPLITTER\sUTIME\n +データ中にBoundaryが現れた場合、行末に半角スペースを加える ++保存データに手を加えるので処理としては良くない ++PKWK_SPLITTERは過去にはglobal $splitter ++\sに半角スペース以外が使われた事はない +zlib extensionの有無でファイル形式が変わる((PHP 4.3.0 以降、zlib モジュールは php バイナリにビルトインされたため、PHP4.2.x以前＋zlibなし→PHP4.3.0以降でのみ発生する)) ++設置サーバーの状況が変わると手作業しか移行手段がない(zlib無で.gz対応は不可能) ++Boundaryも含めて圧縮されるので、一部の損傷が全滅につながる ***lib/backup.php内で外部からコールされる関数 [#ybb94d95] -make_backup 特定のページのバックアップ追加処理 -get_backup 特定のページのバックアップ全データの取得、世代を指定した場合はその世代の全データのみ取得 --過去には一覧の取得と各データ取得で分けられていたようだが、今は全取得しか使われていない -_backup_file_exists 特定のページのバックアップの有無確認 -_backup_delete 特定のページのバックアップの全削除 -直接データ構造にアクセスする個所 --plugin/dump.inc.php --plugin/backup.inc.php(バックアップの存在する全ページ名の一覧取得・表示、特定のページの世代一覧の表示など) --plugin/deleted.inc.php --plugin/rename.inc.php ***backup.inc.phpとの連携部など [#sad248ef] +常に解凍された全データを要求する ++複数回のファイル読み込みと解凍を要さない ++バックアップファイルが大きくなると処理の負荷が大きい([[BugTrack/732]],[[BugTrack2/159]]) +各バックアップは世代番号で管理される。世代番号はバックアップファイル内に存在する順で割り当てられる ++一覧表示から各データの取得までにバックアップ処理が起こると世代番号がずれる +バックアップ日時は、そのページの前回の最終更新日時(そのデータが作られた日時)が割り当てられる ++タイムスタンプを変更しない編集を繰り返すと同じタイムスタンプのバックアップが複数作られる([[BugTrack/685]]) +$cycle=0 でも同一タイムスタンプでバックアップは働かない ++重いバックアップ処理を連打されずにすむ ++UTIMEでtouchはしていないので処理が重い場合など若干のずれが生じる #comment ** 問題点 [#p5cf8c63] *** backupに対する既存の機能要望 [#xda38abf] +自動生成されるページを含めて基本は全ページが対象([[BugTrack/708]]) +世代を指定してバックアップを削除できない([[official:欲しいプラグイン/137]]) +バックアッップの特定の世代からwikiソースをコピー（ロールバック）して編集したい([[BugTrack/507]],[[BugTrack2/53]],[[official:欲しいプラグイン/188]]) +通常バックアップと別に版管理を行いたい([[BugTrack2/86]]) --バックアップ時刻の外に一覧用の別データを埋め込める構造にする？要望した人は別の方法を見付けたみたいですが。 + backupじゃなくて(あるいは選択式で)データベースが使えるようになって欲しい --lib/backup.phpをカプセル化して標準データとの相互変換コードを用意すれば内部構造をどう変えても対応可能 +ページが（部分）削除された場合には、通常サイクルとは別基準できめ細かくバックアップを実行したい([[PukiWiki/1.4/ちょっと便利に/バックアップを少しだけ荒らしに強く]]) - ちょっと便利に～の1件を追記 -- &new{2016-01-18 (月) 20:44:31}; #comment **改善案 [#j62ef48c] ***1ファイルは維持し、日付部分は圧縮しない案 [#f7b3dda2] +ファイル読み込み・一覧作成の段階で解凍は発生しないので比較的低負荷 +一部が損傷しても全体に影響は及ばない +ディスクスペースは若干増える +圧縮部分に偶然Boundaryが現れる可能性にどう対処するか ++普通は各ブロックサイズを記録しておいてfseekしながら飛ばし読みする ++飛ばし読みのみでは一部の欠落等の事故に対応できない ++multipart-mixedのような動的にBoundaryを生成する方法が無難 ***各バックアップ世代をページ名のディレクトリ下に独立ファイル化する案 [#ybc4136a] +一覧作成はディレクトリ検索速度に依存する(必要メモリは少ないが、システムコールは多いはず) +一部が損傷しても全体に影響は及ばない +ディスクスペースは増える(特にFATファイルシステムで) +Boundaryとバックアップ読み込み時のflock処理が不要 +特定の世代だけ削除するのが容易(ftpでも可能) +dump.inc.phpが1ファイル状態を前提にファイルにアクセスしている ++データ構造に直接アクセスすべきではない。必要ならAPIを作る。 ***CVS likeに差分のみで全体を構成する案 [#a33815f5] +無圧縮でも非常に小さいサイズになる ++昨今の状況ではディスクスペースをそれほど重視しなくて良いのでは？ ***世代管理にバックアップ時刻を使う案 [#s2f006dc] +ページのタイムスタンプを変更しなくても編集した時刻が分かってしまう ++Recentには影響しないので構わないのでは？ +ページの最終更新日時はlast-modified headerにも使われるので、タイムスタンプを更新しない場合でも変更した方が良いはず。Recentに入れない等の処理は別の方法で実現した方が良いのでは？ +暫定的に差分の最終更新日時から得る方法もあり ***lib/backup.phpに必要とされるAPI [#e61473b0] +バックアップの追加 (現在のmake_backup関数) +バックアップの有無 (現在の_backup_file_exists関数) +バックアップデータ一覧の取得 --現在のget_backup関数で世代指定を省略した時は、全世代のwikiソースと他データ（タイムスタンプ）を同時に取得する +ある世代のバックアップデータの取得 --現在のget_backup関数で世代を指定した時は、その世代のwikiソースと他データ（タイムスタンプ）を同時に取得する（内部的には、いったんすべてを読み込んでから抽出） +バックアップの全削除 (現在の_backup_delete関数) +バックアップの部分削除 +バックアップの存在する全ページ名の一覧取得 --現状の1.4.xでは、呼び出し側に内包されて存在 +バックアップデータを標準データと相互変換する機能 +renameに対応する機能 -get_backupでの全取得はやめる -どの形式を標準データにするか？ --互換性で問題がないのは現在の構造で無圧縮 -dump.inc.phpは標準データを扱うようにする -バックアップデータの変換はタイムアウト対策が必須 -バックアップデータを一行ずつの配列(file()で読み込んだソース相当)で渡す必要はないのでは？ --(array)$multi_line_strの形で返しても問題無いみたいです ---- -過去(現状の調査と把握)を踏まえて進めようとされていて、ここにわかり易く解説していらっしゃる、それだけでも素晴らしい仕事だと思います ;) -- [[henoheno]] &new{2005-09-01 (木) 23:10:03}; -他に気付いた点や案があれば追加お願いします。 -- [[Cue]] &new{2005-09-03 (土) 00:39:25}; - 過去ログの世代管理についてですが、logrotateのようにファイル名に.1/.2とつけていく。というだけでも良い気がします。 -- [[romap]] &new{2005-09-15 (木) 14:18:45}; - ディレクトリを読むだけで一覧に必要な情報を取得できるようにしたかったので差分の最終更新日時(＝バックアップするデータの更新日時)をファイル名にしてみました。同一日時がある場合に一秒加算でなく.1,.2を付けていく手は有りだと思います。 -- [[Cue]] &new{2005-09-15 (木) 19:14:08}; -- 気付いたのですが、ページ毎にディレクトリ分けせず「ページ名.No.gz」といった形で保存する方法はbackup/下のファイル総数がページ数×保存世代数になるので速度的にきつそうなことと、ファイル名の長さ制限の問題が起こりそうなので見送りました。 -- [[Cue]] &new{2005-09-21 (水) 00:13:37}; - 古いネタに反応してすいません。「zlib extensionの有無でファイル形式が変わる」でハマったので、改善の検討をお願いしたいです。 - zlibありなんだけどバックアップファイルが*.txtで存在する場合は*.txtでバックアップを保存 - zlibなしなんだけどバックアップファイルが*.gzで存在する場合は「バックアップが保存されないけどいい?」と確認を促す といった感じで。あ、zlibで圧縮する場合の拡張子は*.gzではなくて*.txt.gzがいいようなきがします。 -- [[よっちい]] &new{2008-04-14 (月) 23:12:46}; #comment ** 実装案 [#g5fd6c9d] - => [[BugTrack2/103/idea1]] * See also [#c8343a63] - [[BugTrack2/374]] どのユーザーがページを変更したかの記録を残したい
タイムスタンプを変更しない
*バックアップデータ構造の改善 [#pc299b0e] -ページ: [[BugTrack2]] -投稿者: [[Cue]] -優先順位: 低 -状態: 保留 -カテゴリー: 本体新機能 -投稿日: 2005-08-31 (水) 03:50:07 -バージョン: #contents **メッセージ [#v43ed818] **従来の仕様と特徴 (- PukiWiki 1.4.6) [#m5a5c2e9] ***バックアップファイル構造 [#i562cea6] +バックアップファイル1ファイルの中にそのページの全ての世代が保存されている ++ディスクスペースは少なくて良い(特に小さいページが沢山ある場合) +Boundaryは、PKWK_SPLITTER\sUTIME\n +データ中にBoundaryが現れた場合、行末に半角スペースを加える ++保存データに手を加えるので処理としては良くない ++PKWK_SPLITTERは過去にはglobal $splitter ++\sに半角スペース以外が使われた事はない +zlib extensionの有無でファイル形式が変わる((PHP 4.3.0 以降、zlib モジュールは php バイナリにビルトインされたため、PHP4.2.x以前＋zlibなし→PHP4.3.0以降でのみ発生する)) ++設置サーバーの状況が変わると手作業しか移行手段がない(zlib無で.gz対応は不可能) ++Boundaryも含めて圧縮されるので、一部の損傷が全滅につながる ***lib/backup.php内で外部からコールされる関数 [#ybb94d95] -make_backup 特定のページのバックアップ追加処理 -get_backup 特定のページのバックアップ全データの取得、世代を指定した場合はその世代の全データのみ取得 --過去には一覧の取得と各データ取得で分けられていたようだが、今は全取得しか使われていない -_backup_file_exists 特定のページのバックアップの有無確認 -_backup_delete 特定のページのバックアップの全削除 -直接データ構造にアクセスする個所 --plugin/dump.inc.php --plugin/backup.inc.php(バックアップの存在する全ページ名の一覧取得・表示、特定のページの世代一覧の表示など) --plugin/deleted.inc.php --plugin/rename.inc.php ***backup.inc.phpとの連携部など [#sad248ef] +常に解凍された全データを要求する ++複数回のファイル読み込みと解凍を要さない ++バックアップファイルが大きくなると処理の負荷が大きい([[BugTrack/732]],[[BugTrack2/159]]) +各バックアップは世代番号で管理される。世代番号はバックアップファイル内に存在する順で割り当てられる ++一覧表示から各データの取得までにバックアップ処理が起こると世代番号がずれる +バックアップ日時は、そのページの前回の最終更新日時(そのデータが作られた日時)が割り当てられる ++タイムスタンプを変更しない編集を繰り返すと同じタイムスタンプのバックアップが複数作られる([[BugTrack/685]]) +$cycle=0 でも同一タイムスタンプでバックアップは働かない ++重いバックアップ処理を連打されずにすむ ++UTIMEでtouchはしていないので処理が重い場合など若干のずれが生じる #comment ** 問題点 [#p5cf8c63] *** backupに対する既存の機能要望 [#xda38abf] +自動生成されるページを含めて基本は全ページが対象([[BugTrack/708]]) +世代を指定してバックアップを削除できない([[official:欲しいプラグイン/137]]) +バックアッップの特定の世代からwikiソースをコピー（ロールバック）して編集したい([[BugTrack/507]],[[BugTrack2/53]],[[official:欲しいプラグイン/188]]) +通常バックアップと別に版管理を行いたい([[BugTrack2/86]]) --バックアップ時刻の外に一覧用の別データを埋め込める構造にする？要望した人は別の方法を見付けたみたいですが。 + backupじゃなくて(あるいは選択式で)データベースが使えるようになって欲しい --lib/backup.phpをカプセル化して標準データとの相互変換コードを用意すれば内部構造をどう変えても対応可能 +ページが（部分）削除された場合には、通常サイクルとは別基準できめ細かくバックアップを実行したい([[PukiWiki/1.4/ちょっと便利に/バックアップを少しだけ荒らしに強く]]) - ちょっと便利に～の1件を追記 -- &new{2016-01-18 (月) 20:44:31}; #comment **改善案 [#j62ef48c] ***1ファイルは維持し、日付部分は圧縮しない案 [#f7b3dda2] +ファイル読み込み・一覧作成の段階で解凍は発生しないので比較的低負荷 +一部が損傷しても全体に影響は及ばない +ディスクスペースは若干増える +圧縮部分に偶然Boundaryが現れる可能性にどう対処するか ++普通は各ブロックサイズを記録しておいてfseekしながら飛ばし読みする ++飛ばし読みのみでは一部の欠落等の事故に対応できない ++multipart-mixedのような動的にBoundaryを生成する方法が無難 ***各バックアップ世代をページ名のディレクトリ下に独立ファイル化する案 [#ybc4136a] +一覧作成はディレクトリ検索速度に依存する(必要メモリは少ないが、システムコールは多いはず) +一部が損傷しても全体に影響は及ばない +ディスクスペースは増える(特にFATファイルシステムで) +Boundaryとバックアップ読み込み時のflock処理が不要 +特定の世代だけ削除するのが容易(ftpでも可能) +dump.inc.phpが1ファイル状態を前提にファイルにアクセスしている ++データ構造に直接アクセスすべきではない。必要ならAPIを作る。 ***CVS likeに差分のみで全体を構成する案 [#a33815f5] +無圧縮でも非常に小さいサイズになる ++昨今の状況ではディスクスペースをそれほど重視しなくて良いのでは？ ***世代管理にバックアップ時刻を使う案 [#s2f006dc] +ページのタイムスタンプを変更しなくても編集した時刻が分かってしまう ++Recentには影響しないので構わないのでは？ +ページの最終更新日時はlast-modified headerにも使われるので、タイムスタンプを更新しない場合でも変更した方が良いはず。Recentに入れない等の処理は別の方法で実現した方が良いのでは？ +暫定的に差分の最終更新日時から得る方法もあり ***lib/backup.phpに必要とされるAPI [#e61473b0] +バックアップの追加 (現在のmake_backup関数) +バックアップの有無 (現在の_backup_file_exists関数) +バックアップデータ一覧の取得 --現在のget_backup関数で世代指定を省略した時は、全世代のwikiソースと他データ（タイムスタンプ）を同時に取得する +ある世代のバックアップデータの取得 --現在のget_backup関数で世代を指定した時は、その世代のwikiソースと他データ（タイムスタンプ）を同時に取得する（内部的には、いったんすべてを読み込んでから抽出） +バックアップの全削除 (現在の_backup_delete関数) +バックアップの部分削除 +バックアップの存在する全ページ名の一覧取得 --現状の1.4.xでは、呼び出し側に内包されて存在 +バックアップデータを標準データと相互変換する機能 +renameに対応する機能 -get_backupでの全取得はやめる -どの形式を標準データにするか？ --互換性で問題がないのは現在の構造で無圧縮 -dump.inc.phpは標準データを扱うようにする -バックアップデータの変換はタイムアウト対策が必須 -バックアップデータを一行ずつの配列(file()で読み込んだソース相当)で渡す必要はないのでは？ --(array)$multi_line_strの形で返しても問題無いみたいです ---- -過去(現状の調査と把握)を踏まえて進めようとされていて、ここにわかり易く解説していらっしゃる、それだけでも素晴らしい仕事だと思います ;) -- [[henoheno]] &new{2005-09-01 (木) 23:10:03}; -他に気付いた点や案があれば追加お願いします。 -- [[Cue]] &new{2005-09-03 (土) 00:39:25}; - 過去ログの世代管理についてですが、logrotateのようにファイル名に.1/.2とつけていく。というだけでも良い気がします。 -- [[romap]] &new{2005-09-15 (木) 14:18:45}; - ディレクトリを読むだけで一覧に必要な情報を取得できるようにしたかったので差分の最終更新日時(＝バックアップするデータの更新日時)をファイル名にしてみました。同一日時がある場合に一秒加算でなく.1,.2を付けていく手は有りだと思います。 -- [[Cue]] &new{2005-09-15 (木) 19:14:08}; -- 気付いたのですが、ページ毎にディレクトリ分けせず「ページ名.No.gz」といった形で保存する方法はbackup/下のファイル総数がページ数×保存世代数になるので速度的にきつそうなことと、ファイル名の長さ制限の問題が起こりそうなので見送りました。 -- [[Cue]] &new{2005-09-21 (水) 00:13:37}; - 古いネタに反応してすいません。「zlib extensionの有無でファイル形式が変わる」でハマったので、改善の検討をお願いしたいです。 - zlibありなんだけどバックアップファイルが*.txtで存在する場合は*.txtでバックアップを保存 - zlibなしなんだけどバックアップファイルが*.gzで存在する場合は「バックアップが保存されないけどいい?」と確認を促す といった感じで。あ、zlibで圧縮する場合の拡張子は*.gzではなくて*.txt.gzがいいようなきがします。 -- [[よっちい]] &new{2008-04-14 (月) 23:12:46}; #comment ** 実装案 [#g5fd6c9d] - => [[BugTrack2/103/idea1]] * See also [#c8343a63] - [[BugTrack2/374]] どのユーザーがページを変更したかの記録を残したい
テキスト整形のルールを表示する
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
