DB変更並列作業のためのAlterCheckのリニューアル
79 views
Skip to first unread message
kubo
Aug 18, 2019, 2:50:05 AM8/18/19
to DBFluteユーザの集い
jfluteです
DBFlute Slack でのフィードバックより、AlterCheckに以下の problem があることがわかりました。
(zipに関しては既知のものでしたが、並列作業はフィードバックで初めてわかったものです)
```
o problem: 並列作業(AさんとBさんが同時にDB変更)の際に、すれ違いが発生して手順がややこしくなる
o problem: AlterDDLをzipにしてしまうので、github上でのレビューがしづらい
o problem: オペレーションに不慣れなメンバーがときどき間違える (チームでDB変更している場合)
```
これをきっかけに、2011年に開発してから初の「AlterCheckリニューアル」をしようかなと思っています。
とはいえ、物理的・精神的な互換性などはできるだけキープしたいと思っています。
それぞれの problem に対する try と requirement をまとめました。
```
o problem: AlterCheckで、並列作業(AさんとBさんが同時にDB変更)の際に、すれ違いが発生して手順がややこしくなる
=> try: DBFluteでAlterCheckのリニューアル、すれ違いを発生させないようにする
=> requirement: スプリントをまたがったマージによるすれ違いもあるので、それを安全にしたい
=> requirement: 物理的な互換性キープ - DBFluteのアップグレードで物理的な移行作業が必要にならないように
=> requirement: 精神的な互換性キープ - AlterCheckを利用するディベロッパーができるだけ自然と移行できるように
=> requirement: タイミング的な互換性キープ - スプリント途中でアップグレードしても継続できるように
=> requirement: jfluteが関わってない現場でアップグレードしてもトラブらないようにしたい
o problem: AlterCheckで、DDLをzipにしてしまうので、github上でのレビューがしづらい
=> try: DBFluteのAlterCheckのリニューアルで、同時に直す
=> requirement: 修正ファイル間違えが発生しづらいというメリットはなくなるので、それは補完したい
=> requirement: PreviousDDLとのマッピングがわかりやすいメリットはなくなるので、それは補完したい
=> requirement: (そもそもスプリントまたがりマージ問題も解決しないとけない)
o problem: AlterCheckのオペレーションに不慣れなメンバーが多く間違えやすい
=> try: DBFlute Intro (GUI) で AlterCheck のオペレーション支援
```
このMLスレッドで、さらに具体的な改善案を投稿していく予定です。
細かい背景や実況中継などは、DBFlute Slack を御覧ください。
DBFlute ML ではまとまった単位で情報共有していきたいと思います。
意見ありましたら、ML でも Slack でもどちらでもお気軽に。
DBFlute Slack でのフィードバックより、AlterCheckに以下の problem があることがわかりました。
(zipに関しては既知のものでしたが、並列作業はフィードバックで初めてわかったものです)
```
o problem: 並列作業(AさんとBさんが同時にDB変更)の際に、すれ違いが発生して手順がややこしくなる
o problem: AlterDDLをzipにしてしまうので、github上でのレビューがしづらい
o problem: オペレーションに不慣れなメンバーがときどき間違える (チームでDB変更している場合)
```
これをきっかけに、2011年に開発してから初の「AlterCheckリニューアル」をしようかなと思っています。
とはいえ、物理的・精神的な互換性などはできるだけキープしたいと思っています。
それぞれの problem に対する try と requirement をまとめました。
```
o problem: AlterCheckで、並列作業(AさんとBさんが同時にDB変更)の際に、すれ違いが発生して手順がややこしくなる
=> try: DBFluteでAlterCheckのリニューアル、すれ違いを発生させないようにする
=> requirement: スプリントをまたがったマージによるすれ違いもあるので、それを安全にしたい
=> requirement: 物理的な互換性キープ - DBFluteのアップグレードで物理的な移行作業が必要にならないように
=> requirement: 精神的な互換性キープ - AlterCheckを利用するディベロッパーができるだけ自然と移行できるように
=> requirement: タイミング的な互換性キープ - スプリント途中でアップグレードしても継続できるように
=> requirement: jfluteが関わってない現場でアップグレードしてもトラブらないようにしたい
o problem: AlterCheckで、DDLをzipにしてしまうので、github上でのレビューがしづらい
=> try: DBFluteのAlterCheckのリニューアルで、同時に直す
=> requirement: 修正ファイル間違えが発生しづらいというメリットはなくなるので、それは補完したい
=> requirement: PreviousDDLとのマッピングがわかりやすいメリットはなくなるので、それは補完したい
=> requirement: (そもそもスプリントまたがりマージ問題も解決しないとけない)
o problem: AlterCheckのオペレーションに不慣れなメンバーが多く間違えやすい
=> try: DBFlute Intro (GUI) で AlterCheck のオペレーション支援
```
このMLスレッドで、さらに具体的な改善案を投稿していく予定です。
細かい背景や実況中継などは、DBFlute Slack を御覧ください。
DBFlute ML ではまとまった単位で情報共有していきたいと思います。
意見ありましたら、ML でも Slack でもどちらでもお気軽に。
kubo
Aug 18, 2019, 11:48:10 PM8/18/19
to DBFluteユーザの集い
jfluteです
問題分析の補足です。
AlterCheckにおける「すれ違い」についての詳しくまとめます。
※スプリントという言葉が出てきますが、
運用中にサービスをスクラムでインクリメンタル開発していくイメージしてください。
(例えば、二週間の一回のスプリントの中で発生した複数のDB変更をリリースしたら次のスプリント)
<< 並列作業時のすれ違い >>
オーソドックスなすれ違いです。
並列作業というのはAさんとBさんがそれぞれの別ブランチで別のDB変更作業をしてから、
それぞれのブランチをマージをすることです。
AlterCheckは、DB変更開始時に「とりあえずAlterCheck実行」することで、
すでに同じスプリントで別の人が AlterCheck をしていたら、そのSQLファイルがhistoryから復元されます。
その復元されたSQLファイルをベースに、これからやろうとしているDB変更を書いていきます。
(そのとき、別のファイルにしてもいいし、同じファイルに追記してもどちらでも構いません)
その復元処理で、すれ違いが発生してしまいます。
/- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| dbflute_maihamadb
| |-...
| |-playsql
| | |-migration
| | | |-alter
| | | | |-alter-schema-ABC002.sql // 直近のzipから復元したもの ★ABC001は復元されない
| | | | |-alter-schema-ABC003.sql // 新規のDDLファイル
| | | |
| | | |-history
| | | | |-[date directory]
| | | | | |-[date-time directory] e.g. 20190415-1234
| | | | | | |-finished-alter-...zip
| | | | | |
| | | | | |-[date-time directory] e.g. 20190712-1111
| | | | | | |-checked-alter-...zip // ABC001, ★並列でこの可能性、置き去りにされる
| | | | | |
| | | | | |-[date-time directory] e.g. 20190712-1212
| | | | | | |-checked-alter-...zip // ABC002
| | | | | |
| | | |-previous
- - - - - - - - - -/
二つ不都合があって...
ひとつめ、AlterCheckが終わると、history の中に checked-alter...zip ができます。
この zip ファイルは、日付と時分のディレクトリで管理されています。秒は入っていません。
ゆえに、AさんとBさんが、分単位で同じタイミングでAlterCheckすると、gitでzipのコンフリクトになります。
(これ自体はめったにないことではありますが、可能性としてあり得ます)
ふたつめ、そのzipのコンフリクトが避けられたとしても、AさんとBさんが並列作業してDB変更を終えてマージすると、
そのマージされたブランチでは history の中に checked-alter...zip が二つできてしまいます。
このブランチを元に、Cさんが新たなDB変更をしようとして AlterCheck を流しても、
どちらか片方の zip しか復元されません。日時的に近いほうが選ばれます。
すると、Cさんがいくら自分のDB変更を満たすDDLを正しく書いたとしても、
置き去りにされたAさんorBさんのAlterDDLがないので、その差分が発生してしまい、AlterCheckが通りません。
それに気付いて、置き去りにされたzipのSQLファイルを手動で展開してAlterCheckしないといけません。
また、Cさんがいなかったとき、つまり、そのスプリントで誰もDB変更する人がいなかったとき、
リリース時は checked-alter...zip が二つあることに気付いて展開しなければなりません。
片方だけを展開して作業してしまうと、アプリケーションとDBがズレてしまいます。
...
DB変更の並列作業を行っている現場は、jfluteの知っている限り一つの現場です。
そのきっかけも単純にDB変更の数が多いというよりも、DB変更後にDBAレビューをやるようにしていて、
DBAが忙しく3日間レビュー待ちになると、その間に別の人がDB変更作業できないという理由が大きいようです。
DB変更フローやレビューの仕方・タイミングとか現場によって違ったりするので、
並列作業の必要性や、並列作業しても不都合が発生するかどうかは現場によりけりです。
いずれにせよ ERFlute は同時にDB変更できると謳っていますので、
AlterCheck も並列作業に耐えやすい作りにする必要があると考えています。
...
...
...
<< スプリントまたがりのマージ >>
少しマニアックなすれ違いですが、あり得なくはないです。
例えば、Aさんがスプリント3でDB変更をしたとします。
ただ、そのときリリースしませんでした。とある事情でその機能を保留したとします。
時は経ち、Bさんがスプリント7でDB変更をしたとします。
一方で、Aさんがスプリント3時代に作った機能をようやくこのスプリント7でリリースすることになったとします。
ゆえに、Aさんの古いブランチを今のブランチにマージするとします。
すると、並列作業と同じことが発生します。checked-alter...zip が二つできあがってしまいます。
一見、並列作業と同じ問題を抱えるだけに見えますが、別のスプリントのAlterDDLが混ざることによる不具合があります。
別のスプリントのAlterDDLは今のSavePreviousされたDBでちゃんと動くDDLなのか確証がありません。
スプリント4,5,6の間にDBの構造が変わって、スプリント3時代のAlterDDLが落ちる可能性があります。
ゆえに、古い時代のAlterDDLは、改めて今のDBで AlterCheck されるべきと言えます。
スプリントまたがりのマージ:
/- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
dbflute_maihamadb
| |-...
| |-playsql
| | |-migration
| | | |-alter
| | | | |-alter-schema-ABC002.sql // 直近のzipから復元したもの ★ABC001は復元されない
| | | | |-alter-schema-ABC003.sql // 新規のDDLファイル
| | | |
| | | |-history
| | | | |-[date directory]
| | | | | |-[date-time directory] e.g. 20190415-1234
| | | | | | |-finished-alter-...zip
| | | | | |
| | | | | |-[date-time directory] e.g. 20190615-2356
★古いDBに対するチェックなので再チェックしたい
| | | | | | |-checked-alter-[古いDB]...zip // ABC001,
★過去スプリントマージでこの可能性、置き去りにされる
| | | | | |
| | | | | |-[date-time directory] e.g. 20190712-2222
| | | | | | |-checked-alter-[今のDB]...zip // ABC002
| | | | | |
| | | |-previous
| | | | |-★previousのzipが二個になる (変ではあるけど動作的には大丈夫、いずれ自然と削除される)
- - - - - - - - - -/
もしCさんが新たにスプリント7でDB変更をするのであれば、checked-alter...zipが二つになる問題はあるにせよ、
そこで自然とAさんのAlterDDLが新たにAlterCheckされます。落ちるのであればそのときに気付けます。
ですが、CさんがDB変更しないとなると、スプリント3時代のAlterDDLが検証環境・本番環境で実行される可能性があります。
(当然、落ちるとしたら検証環境で気付けるというのはありますが、あまり良いことではないです)
ただ、AlterDDLが落ちるような場合は、create 文とかテストデータとか ReplaceSchema のリソースの方で、
そもそもgitコンフリクトが起きて気付くという可能性は大いにありますので、確率は低いことかもしれません。
また、スプリントまたがりのマージを実際にするかと言ったら、jfluteがヒアリングした範囲の中では、
どの現場もそんなことはしないし、するのであればやり直す、という話でした。
とはいえ、AlterCheck としては、できるだけ安全にしたいという気持ちがあります。
問題分析の補足です。
AlterCheckにおける「すれ違い」についての詳しくまとめます。
※スプリントという言葉が出てきますが、
運用中にサービスをスクラムでインクリメンタル開発していくイメージしてください。
(例えば、二週間の一回のスプリントの中で発生した複数のDB変更をリリースしたら次のスプリント)
<< 並列作業時のすれ違い >>
オーソドックスなすれ違いです。
並列作業というのはAさんとBさんがそれぞれの別ブランチで別のDB変更作業をしてから、
それぞれのブランチをマージをすることです。
AlterCheckは、DB変更開始時に「とりあえずAlterCheck実行」することで、
すでに同じスプリントで別の人が AlterCheck をしていたら、そのSQLファイルがhistoryから復元されます。
その復元されたSQLファイルをベースに、これからやろうとしているDB変更を書いていきます。
(そのとき、別のファイルにしてもいいし、同じファイルに追記してもどちらでも構いません)
その復元処理で、すれ違いが発生してしまいます。
/- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| dbflute_maihamadb
| |-...
| |-playsql
| | |-migration
| | | |-alter
| | | | |-alter-schema-ABC002.sql // 直近のzipから復元したもの ★ABC001は復元されない
| | | | |-alter-schema-ABC003.sql // 新規のDDLファイル
| | | |
| | | |-history
| | | | |-[date directory]
| | | | | |-[date-time directory] e.g. 20190415-1234
| | | | | | |-finished-alter-...zip
| | | | | |
| | | | | |-[date-time directory] e.g. 20190712-1111
| | | | | | |-checked-alter-...zip // ABC001, ★並列でこの可能性、置き去りにされる
| | | | | |
| | | | | |-[date-time directory] e.g. 20190712-1212
| | | | | | |-checked-alter-...zip // ABC002
| | | | | |
| | | |-previous
- - - - - - - - - -/
二つ不都合があって...
ひとつめ、AlterCheckが終わると、history の中に checked-alter...zip ができます。
この zip ファイルは、日付と時分のディレクトリで管理されています。秒は入っていません。
ゆえに、AさんとBさんが、分単位で同じタイミングでAlterCheckすると、gitでzipのコンフリクトになります。
(これ自体はめったにないことではありますが、可能性としてあり得ます)
ふたつめ、そのzipのコンフリクトが避けられたとしても、AさんとBさんが並列作業してDB変更を終えてマージすると、
そのマージされたブランチでは history の中に checked-alter...zip が二つできてしまいます。
このブランチを元に、Cさんが新たなDB変更をしようとして AlterCheck を流しても、
どちらか片方の zip しか復元されません。日時的に近いほうが選ばれます。
すると、Cさんがいくら自分のDB変更を満たすDDLを正しく書いたとしても、
置き去りにされたAさんorBさんのAlterDDLがないので、その差分が発生してしまい、AlterCheckが通りません。
それに気付いて、置き去りにされたzipのSQLファイルを手動で展開してAlterCheckしないといけません。
また、Cさんがいなかったとき、つまり、そのスプリントで誰もDB変更する人がいなかったとき、
リリース時は checked-alter...zip が二つあることに気付いて展開しなければなりません。
片方だけを展開して作業してしまうと、アプリケーションとDBがズレてしまいます。
...
DB変更の並列作業を行っている現場は、jfluteの知っている限り一つの現場です。
そのきっかけも単純にDB変更の数が多いというよりも、DB変更後にDBAレビューをやるようにしていて、
DBAが忙しく3日間レビュー待ちになると、その間に別の人がDB変更作業できないという理由が大きいようです。
DB変更フローやレビューの仕方・タイミングとか現場によって違ったりするので、
並列作業の必要性や、並列作業しても不都合が発生するかどうかは現場によりけりです。
いずれにせよ ERFlute は同時にDB変更できると謳っていますので、
AlterCheck も並列作業に耐えやすい作りにする必要があると考えています。
...
...
...
<< スプリントまたがりのマージ >>
少しマニアックなすれ違いですが、あり得なくはないです。
例えば、Aさんがスプリント3でDB変更をしたとします。
ただ、そのときリリースしませんでした。とある事情でその機能を保留したとします。
時は経ち、Bさんがスプリント7でDB変更をしたとします。
一方で、Aさんがスプリント3時代に作った機能をようやくこのスプリント7でリリースすることになったとします。
ゆえに、Aさんの古いブランチを今のブランチにマージするとします。
すると、並列作業と同じことが発生します。checked-alter...zip が二つできあがってしまいます。
一見、並列作業と同じ問題を抱えるだけに見えますが、別のスプリントのAlterDDLが混ざることによる不具合があります。
別のスプリントのAlterDDLは今のSavePreviousされたDBでちゃんと動くDDLなのか確証がありません。
スプリント4,5,6の間にDBの構造が変わって、スプリント3時代のAlterDDLが落ちる可能性があります。
ゆえに、古い時代のAlterDDLは、改めて今のDBで AlterCheck されるべきと言えます。
スプリントまたがりのマージ:
/- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
dbflute_maihamadb
| |-...
| |-playsql
| | |-migration
| | | |-alter
| | | | |-alter-schema-ABC002.sql // 直近のzipから復元したもの ★ABC001は復元されない
| | | | |-alter-schema-ABC003.sql // 新規のDDLファイル
| | | |
| | | |-history
| | | | |-[date directory]
| | | | | |-[date-time directory] e.g. 20190415-1234
| | | | | | |-finished-alter-...zip
| | | | | |
| | | | | |-[date-time directory] e.g. 20190615-2356
★古いDBに対するチェックなので再チェックしたい
| | | | | | |-checked-alter-[古いDB]...zip // ABC001,
★過去スプリントマージでこの可能性、置き去りにされる
| | | | | |
| | | | | |-[date-time directory] e.g. 20190712-2222
| | | | | | |-checked-alter-[今のDB]...zip // ABC002
| | | | | |
| | | |-previous
| | | | |-★previousのzipが二個になる (変ではあるけど動作的には大丈夫、いずれ自然と削除される)
- - - - - - - - - -/
もしCさんが新たにスプリント7でDB変更をするのであれば、checked-alter...zipが二つになる問題はあるにせよ、
そこで自然とAさんのAlterDDLが新たにAlterCheckされます。落ちるのであればそのときに気付けます。
ですが、CさんがDB変更しないとなると、スプリント3時代のAlterDDLが検証環境・本番環境で実行される可能性があります。
(当然、落ちるとしたら検証環境で気付けるというのはありますが、あまり良いことではないです)
ただ、AlterDDLが落ちるような場合は、create 文とかテストデータとか ReplaceSchema のリソースの方で、
そもそもgitコンフリクトが起きて気付くという可能性は大いにありますので、確率は低いことかもしれません。
また、スプリントまたがりのマージを実際にするかと言ったら、jfluteがヒアリングした範囲の中では、
どの現場もそんなことはしないし、するのであればやり直す、という話でした。
とはいえ、AlterCheck としては、できるだけ安全にしたいという気持ちがあります。
kubo
Aug 20, 2019, 12:17:24 PM8/20/19
to DBFluteユーザの集い
jfluteです
実装案を出す前に、
「実装案の判断ポイント」を明確にしておきます。
<< 実装案の判断ポイント >>
o problemが解決されること
o 物理的、精神的、タイミング的な互換性をキープ
o DBFlute自体の実装コスト、周辺ツールへのインパクト(DBFlute Intro) ※補足A
o ちゃんとチェックされてるブランド(安心性)のキープ ※補足B
[補足A]
タイミング的な互換性などをキープすることを前提とすると、
以前の挙動もサポートした状態で新たな実装をしていかなければならないので、
それなりに実装コストが見込まれる。実装だけじゃなく動作確認コストも高い。
また、DBFlute Introでの画面支援にも影響をできるだけ少なくしたい。
[補足B]
もともとのzipのやり方のメリットとしては、
コミットされたファイルの「ちゃんとチェックされたかどうかのgit上での信頼性」である。
間違ってもわざわざzipを解凍して(AlterCheckせず)修正して圧縮してコミットする人はあまりいないだろうと。
一方で、テキストファイルが展開された状態だと、DB変更(AlterCheck)に不慣れな人が...
「これ修正すればいいのかな？」と勘違いして(AlterCheckせずに)コミットしてしまう可能性もなきにしもあらず。
ゆえに、zip方式をやめるにしても、上記の安心性をできるだけキープしたものにしたい。
引き続き様々な現場でヒアリングをさせて頂いていますが、
この「ちゃんとチェックされてるブランド(安心性)」が重要であるという声を複数頂きました。
人の入れ替わりが激しい、経験浅い人が多い、DBFluteに長けてない人も多いなど、
そういった現場だと安心性が欲しいとのことで、
「確かにzipはgithubで見れないけど、zipはzipで安心感があった」という話も頂きました。
DBFluteとしては両方を得られる策を考えていきたいなと思います。
実装案を出す前に、
「実装案の判断ポイント」を明確にしておきます。
<< 実装案の判断ポイント >>
o problemが解決されること
o 物理的、精神的、タイミング的な互換性をキープ
o DBFlute自体の実装コスト、周辺ツールへのインパクト(DBFlute Intro) ※補足A
o ちゃんとチェックされてるブランド(安心性)のキープ ※補足B
[補足A]
タイミング的な互換性などをキープすることを前提とすると、
以前の挙動もサポートした状態で新たな実装をしていかなければならないので、
それなりに実装コストが見込まれる。実装だけじゃなく動作確認コストも高い。
また、DBFlute Introでの画面支援にも影響をできるだけ少なくしたい。
[補足B]
もともとのzipのやり方のメリットとしては、
コミットされたファイルの「ちゃんとチェックされたかどうかのgit上での信頼性」である。
間違ってもわざわざzipを解凍して(AlterCheckせず)修正して圧縮してコミットする人はあまりいないだろうと。
一方で、テキストファイルが展開された状態だと、DB変更(AlterCheck)に不慣れな人が...
「これ修正すればいいのかな？」と勘違いして(AlterCheckせずに)コミットしてしまう可能性もなきにしもあらず。
ゆえに、zip方式をやめるにしても、上記の安心性をできるだけキープしたものにしたい。
引き続き様々な現場でヒアリングをさせて頂いていますが、
この「ちゃんとチェックされてるブランド(安心性)」が重要であるという声を複数頂きました。
人の入れ替わりが激しい、経験浅い人が多い、DBFluteに長けてない人も多いなど、
そういった現場だと安心性が欲しいとのことで、
「確かにzipはgithubで見れないけど、zipはzipで安心感があった」という話も頂きました。
DBFluteとしては両方を得られる策を考えていきたいなと思います。
kubo
Aug 21, 2019, 1:32:26 AM8/21/19
to DBFluteユーザの集い
jfluteです
それでは実装案です。まずは一つ目。
<< 実装案A: alterディレクトリそのままコミット、markファイルで管理 >>
alterディレクトリで修正してそのままコミット。
AlterCheckされたかどうかの判断は、SQLファイルごとに「チェックされたmarkファイル」で管理。
alter配下がそのまま、そのスプリントでのリリース対象DDLとなる。
SavePreviousしたら、historyへ移動(これは今まで通り)。
以前のDB変更を修正したいときは、普通に alter 配下のSQLファイルを修正するだけ。
```
| | | |-alter-schema-ABC002.sql // 二人目の人がそのままコミット
| | | |-alter-schema-ABC003.sql // 三人目の人が手動で新規作成
| | | |-checked-alter-schema-ABC001-for-previous-20190712-2222.dfmark
// check通ったら自動で作成される
| | | |-checked-alter-schema-ABC002-for-previous-20190712-2222.dfmark
// me too
| | | |
| | | |-(alter-schema-ABC000.sql) // 過去スプリントが混じるとこうなる
| | | |-(checked-alter-schema-ABC000-for-previous-20190601-1111.dfmark)
// 過去スプリントが混じるとこうなる
| | | |-(checked-alter-schema-ABC000-for-previous-20190712-2222.dfmark)
// でもってもう一回やるとこう
| | |
| | |-history // もはやgitignoreでも良い
| | | |-[date directory]
| | | | |-[date-time directory] e.g. 20190415_0123
| | | | | |-finished-alter-...zip // ☆finishedのzipしかなくなる
| | | | |
| | | | ...
| | |
| | |-previous
| | | |-previous-20190712-2222.zip
| | | |-(previous-20190601-1111.zip) // 過去スプリントが混じるとこうなる (現状は無視されて後で削除される)
| | | |-target-previous.dfmark // ★これでスプリント混じりはわざとgitコンフリクトする？
```
メリット:
o 並列作業で何かあっても普通にテキストファイルのgitコンフリクトになる
o 意識するディレクトリが一つになってスッキリ
o 過去スプリント混じりがあっても、わかりやすさはある
デメリット:
o チェックされてるブランド(安心性)が弱い、markファイル作成後に修正される可能性もある
o ひとつの alter-schema.sql に集約しているパターンだと実質的に破綻している
o gitignoreしてるalterディレクトリをコミット対象にする物理的移行が走る
o alterディレクトリは一時作業領域という意識からの精神的な移行が必要
o DBFlute自体の実装コストは高そう、Introへの影響もインパクト大
o alterディレクトリの中に、修正OKファイルと修正ダメファイル(markファイル)が混じるのがわかりづらいかも？
(o jfluteが関わっていない現場でスムーズに移行できるか？)
jfluteの所感:
alter-schema.sql集約パターンはキープしたいのと、ブランド(安心性)と実装コストからちょっと厳しいかも？
alterを修正された後にAlterCheckを実行させることをいかに促進させるか？だが、それは難しい...
それでは実装案です。まずは一つ目。
<< 実装案A: alterディレクトリそのままコミット、markファイルで管理 >>
alterディレクトリで修正してそのままコミット。
AlterCheckされたかどうかの判断は、SQLファイルごとに「チェックされたmarkファイル」で管理。
alter配下がそのまま、そのスプリントでのリリース対象DDLとなる。
SavePreviousしたら、historyへ移動(これは今まで通り)。
以前のDB変更を修正したいときは、普通に alter 配下のSQLファイルを修正するだけ。
```
dbflute_maihamadb
|-...
|-playsql
| |-migration
| | |-alter
| | | |-alter-schema-ABC001.sql // 最初の人がそのままコミット
|-...
|-playsql
| |-migration
| | |-alter
| | | |-alter-schema-ABC002.sql // 二人目の人がそのままコミット
| | | |-alter-schema-ABC003.sql // 三人目の人が手動で新規作成
| | | |-checked-alter-schema-ABC001-for-previous-20190712-2222.dfmark
// check通ったら自動で作成される
| | | |-checked-alter-schema-ABC002-for-previous-20190712-2222.dfmark
// me too
| | | |
| | | |-(alter-schema-ABC000.sql) // 過去スプリントが混じるとこうなる
| | | |-(checked-alter-schema-ABC000-for-previous-20190601-1111.dfmark)
// 過去スプリントが混じるとこうなる
| | | |-(checked-alter-schema-ABC000-for-previous-20190712-2222.dfmark)
// でもってもう一回やるとこう
| | |
| | |-history // もはやgitignoreでも良い
| | | |-[date directory]
| | | | |-[date-time directory] e.g. 20190415_0123
| | | | | |-finished-alter-...zip // ☆finishedのzipしかなくなる
| | | | |
| | | | ...
| | |
| | |-previous
| | | |-previous-20190712-2222.zip
| | | |-(previous-20190601-1111.zip) // 過去スプリントが混じるとこうなる (現状は無視されて後で削除される)
| | | |-target-previous.dfmark // ★これでスプリント混じりはわざとgitコンフリクトする？
```
メリット:
o 並列作業で何かあっても普通にテキストファイルのgitコンフリクトになる
o 意識するディレクトリが一つになってスッキリ
o 過去スプリント混じりがあっても、わかりやすさはある
デメリット:
o チェックされてるブランド(安心性)が弱い、markファイル作成後に修正される可能性もある
o ひとつの alter-schema.sql に集約しているパターンだと実質的に破綻している
o gitignoreしてるalterディレクトリをコミット対象にする物理的移行が走る
o alterディレクトリは一時作業領域という意識からの精神的な移行が必要
o DBFlute自体の実装コストは高そう、Introへの影響もインパクト大
o alterディレクトリの中に、修正OKファイルと修正ダメファイル(markファイル)が混じるのがわかりづらいかも？
(o jfluteが関わっていない現場でスムーズに移行できるか？)
jfluteの所感:
alter-schema.sql集約パターンはキープしたいのと、ブランド(安心性)と実装コストからちょっと厳しいかも？
alterを修正された後にAlterCheckを実行させることをいかに促進させるか？だが、それは難しい...
kubo
Aug 21, 2019, 1:41:01 AM8/21/19
to DBFluteユーザの集い
jfluteです
そして、二つ目の実装案です。
<< 実装案B: 直近チェック済ディレクトリでテキスト展開 >>
チェックされた AlterDDL は、AlterCheckが成功して差分がなくなったら、
history配下の (例えば) latest-checked ディレクトリにテキストファイルのまま退避される。
latest-checked配下がそのまま、そのスプリントでのリリース対象DDLとなる。
SavePreviousすることで初めて finished-alter...zip になる。
以前のDB変更を修正したいときは、latest-checkedから展開されたalter配下のSQLを修正するだけ。
※latest-checked とか READONLY_ の具体的な名前は検討中です。
latest-checkedは他に... already-checked, checked-and-unreleased, などなど
READONLY_は他に... DBFLUTE_MANAGED_, ALREADY_CHECKED_, などなど
```
dbflute_maihamadb
|-...
|-playsql
| |-migration
| | |-alter
| | | |-alter-schema-ABC001.sql // latest-checkedから復元
| | | |-alter-schema-ABC002.sql // latest-checkedから復元
| | | |-alter-schema-ABC003.sql // 手動で新規作成 (将来Introで自動生成したい)
| | |
| | |-history
| | | |-[date directory] // もはやgitignoreでも良い
| | | | |
| | | | ...
| | | |
| | | |-latest-checked // ☆SavePreviousするまでは、すべてここに
| | | | |-DONT_EDIT_HERE.dfmark // こういうの作っておくか？
| | | | |-READONLY_alter-schema-ABC001.sql
| | | | |-READONLY_alter-schema-ABC002.sql
| | | | |-checked-for-previous-20190712-2222.dfmark //
中にファイル名を列挙するとコンフリクトなので空ファイル
| | | | |
| | | | |-(alter-schema-ABC000.sql) // 過去スプリントが混じるとこうなる
| | | | |-(checked-for-previous-20190601-1111.dfmark) //
★別に個別ファイルはわからなくていいかな!?いざとなればgitの差分見れば良い
o alterディレクトリは作業領域、historyはフレームワーク管理領域、今まで同じで精神的な互換性は強い
=> zipやめてリリース前のものがひとまとまりになっただけと言える
o タイミング的互換性も、以前のzip展開処理を残しておきさえすれば実現できそう
o DBFlute実装コスト、そして、DBFlute Introへのインパクトはまあまあ少ない(はず)
o ひとつの alter-schema.sql に集約しているパターンでも普通に実施できる
o チェックされてるブランド(安心性)はまあまあ、latest-checked はチェックされている
デメリット:
o 過去スプリント混じったときに、previousとの対比が少しわかりづらい
=> 過去スプリント混じりは、そもそもgitコンフリクトにさせる (markファイルにて)
o とはいえ latest-checked を修正しちゃう人いないだろうか？
=> なので、フレームワーク管理領域感の強い history の配下に
=> "SQLファイルprefix" や DONT_EDIT_HERE.dfmark で「ついつい作成・修正」をできるだけ防止
jfluteの所感:
バランス良くほうぼうの要件を満たせている。
いかに latest-checked を直接修正させないようにするかだけに注力すれば他は難はあまりない。
...
全体的な補足:
実装案に関わらず、スプリントまたがりのマージは、
target-previous.dfmark でわざとgitコンフリクトさせて、
意識してマージしてもらったほうがいいのかなと思っています。
dfmarkファイルに「ちゃんともう一回AlterCheckしてね」と書いておくとか。
そして、二つ目の実装案です。
<< 実装案B: 直近チェック済ディレクトリでテキスト展開 >>
チェックされた AlterDDL は、AlterCheckが成功して差分がなくなったら、
history配下の (例えば) latest-checked ディレクトリにテキストファイルのまま退避される。
latest-checked配下がそのまま、そのスプリントでのリリース対象DDLとなる。
SavePreviousすることで初めて finished-alter...zip になる。
以前のDB変更を修正したいときは、latest-checkedから展開されたalter配下のSQLを修正するだけ。
※latest-checked とか READONLY_ の具体的な名前は検討中です。
latest-checkedは他に... already-checked, checked-and-unreleased, などなど
READONLY_は他に... DBFLUTE_MANAGED_, ALREADY_CHECKED_, などなど
```
dbflute_maihamadb
|-...
|-playsql
| |-migration
| | |-alter
| | | |-alter-schema-ABC002.sql // latest-checkedから復元
| | | |-alter-schema-ABC003.sql // 手動で新規作成 (将来Introで自動生成したい)
| | |
| | |-history
| | | |-[date directory] // もはやgitignoreでも良い
| | | | |-[date-time directory] e.g. 20190415_0123
| | | | | |-finished-alter-...zip // ☆もう finished のzipしかなくなる
| | | | |
| | | | ...
| | | |
| | | |-latest-checked // ☆SavePreviousするまでは、すべてここに
| | | | |-DONT_EDIT_HERE.dfmark // こういうの作っておくか？
| | | | |-READONLY_alter-schema-ABC001.sql
| | | | |-READONLY_alter-schema-ABC002.sql
| | | | |-checked-for-previous-20190712-2222.dfmark //
中にファイル名を列挙するとコンフリクトなので空ファイル
| | | | |
| | | | |-(alter-schema-ABC000.sql) // 過去スプリントが混じるとこうなる
| | | | |-(checked-for-previous-20190601-1111.dfmark) //
★別に個別ファイルはわからなくていいかな!?いざとなればgitの差分見れば良い
| | |
| | |-previous
| | | |-previous-20190712-2222.zip
| | | |-(previous-20190601-1111.zip) // 過去スプリントが混じるとこうなる (現状は無視されて後で削除される)
| | | |-target-previous.dfmark // ★これでスプリント混じりはわざとgitコンフリクトする？
```
メリット:
o 並列作業で何かあっても普通にテキストファイルのgitコンフリクトになる
o alterディレクトリはgitignoreのままで物理的な互換性は強い
| | |-previous
| | | |-previous-20190712-2222.zip
| | | |-(previous-20190601-1111.zip) // 過去スプリントが混じるとこうなる (現状は無視されて後で削除される)
| | | |-target-previous.dfmark // ★これでスプリント混じりはわざとgitコンフリクトする？
```
メリット:
o 並列作業で何かあっても普通にテキストファイルのgitコンフリクトになる
o alterディレクトリは作業領域、historyはフレームワーク管理領域、今まで同じで精神的な互換性は強い
=> zipやめてリリース前のものがひとまとまりになっただけと言える
o タイミング的互換性も、以前のzip展開処理を残しておきさえすれば実現できそう
o DBFlute実装コスト、そして、DBFlute Introへのインパクトはまあまあ少ない(はず)
o ひとつの alter-schema.sql に集約しているパターンでも普通に実施できる
o チェックされてるブランド(安心性)はまあまあ、latest-checked はチェックされている
デメリット:
o 過去スプリント混じったときに、previousとの対比が少しわかりづらい
=> 過去スプリント混じりは、そもそもgitコンフリクトにさせる (markファイルにて)
o とはいえ latest-checked を修正しちゃう人いないだろうか？
=> なので、フレームワーク管理領域感の強い history の配下に
=> "SQLファイルprefix" や DONT_EDIT_HERE.dfmark で「ついつい作成・修正」をできるだけ防止
jfluteの所感:
バランス良くほうぼうの要件を満たせている。
いかに latest-checked を直接修正させないようにするかだけに注力すれば他は難はあまりない。
...
全体的な補足:
実装案に関わらず、スプリントまたがりのマージは、
target-previous.dfmark でわざとgitコンフリクトさせて、
意識してマージしてもらったほうがいいのかなと思っています。
dfmarkファイルに「ちゃんともう一回AlterCheckしてね」と書いておくとか。
mokkouyou
Aug 21, 2019, 5:13:56 AM8/21/19
to dbf...@googlegroups.com
mokkouyouです。時々マージすることあります(^-^;
ただ、マージする際には対象にsave previousかかっていることが前提です。
ここからがブランドと呼んでいる部分かと思いますが、
自分の今までかけていたcheckについては履歴不要（最新のalterさえあればよい）として最新のだけ退避しておきます。
あとはマージに際して、
er図
exXxx
以外全てマージあきらめて受け入れます。
マージ対象のブランチに、さも今から変更かけていくイメージ。
これが一番わかりやすいかなぁと落ち着きました。
※テストデータのコンフリクトはさすがに泣きますが
gitユーザじゃないのでローカルマージの話ではないとかだったらすみません。
なんにせよ、
・マージを頑張るのは諦める
としてますので、変になんとかなるんじゃないかな？と思えない方が好きかもです。
※以前はヒストリーとかドキュメント系もマージするべきなのか？とか結構悩んだので、、、どうマージするのが正解なのか質問しようとして諦めた過去あります
2019年8月21日(水) 14:41 kubo <dbf...@gmail.com>:
--
このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには dbflute+u...@googlegroups.com にメールを送信してください。
このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msgid/dbflute/CAALfU-D8r0%3D%3Dy-yx6SWvUwzH8qcHcsJK1r%3D%3DnGv1VrfQ%2BnrksA%40mail.gmail.com にアクセスしてください。
kubo
Aug 21, 2019, 1:42:51 PM8/21/19
to DBFluteユーザの集い
jfluteです
mokkouyouさん、めっちゃ久しぶりです！
DBFlute使って続けてくださってるんですね。すごい嬉しいです。
> 時々マージすることあります(^-^;
ありがとうございます。
ぜひ、ユーザーのみなさんの使い方を知りたかったところです。
参考になります！
マージ自体の話に関してですが、
AlterCheckの並列作業は、実質的にER図ツールはERFlute,
そしてテストデータはReplaceSchemaのTSVが前提となります。
ただ、クラスの自動生成まで行うと当然コンフリクトは起きやすくなります。
自動生成クラスや自動生成ファイルでコンフリクト起きたときは、
基本的には取り込んだ上でもう一度自動生成し直せばOKのはずです。
ただ、若干グレーなものがあるかもと考えているところです。
ちょうどその辺タイムリーに現場の方と話をしていて、
AlterCheck一段落したら少し整理してドキュメント書こうかなと思っています。
> 変になんとかなるんじゃないかな？と思えない方が好きかもです
この感覚ありがとうございます(^^。
mokkouyouさん、めっちゃ久しぶりです！
DBFlute使って続けてくださってるんですね。すごい嬉しいです。
> 時々マージすることあります(^-^;
ありがとうございます。
ぜひ、ユーザーのみなさんの使い方を知りたかったところです。
参考になります！
マージ自体の話に関してですが、
AlterCheckの並列作業は、実質的にER図ツールはERFlute,
そしてテストデータはReplaceSchemaのTSVが前提となります。
ただ、クラスの自動生成まで行うと当然コンフリクトは起きやすくなります。
自動生成クラスや自動生成ファイルでコンフリクト起きたときは、
基本的には取り込んだ上でもう一度自動生成し直せばOKのはずです。
ただ、若干グレーなものがあるかもと考えているところです。
ちょうどその辺タイムリーに現場の方と話をしていて、
AlterCheck一段落したら少し整理してドキュメント書こうかなと思っています。
> 変になんとかなるんじゃないかな？と思えない方が好きかもです
この感覚ありがとうございます(^^。
kubo
Aug 22, 2019, 1:05:03 PM8/22/19
to DBFluteユーザの集い
jfluteです
取り急ぎ、やはり総合点の "B" 案で進めていくことに決めました。
取り急ぎ、やはり総合点の "B" 案で進めていくことに決めました。
kubo
Sep 15, 2019, 6:56:53 AM9/15/19
to DBFluteユーザの集い
jfluteです
AlterCheckリニューアル、実装とドキュメント修正だけ終わりました。
これからRC版で現場で試してもらって、最終的に9末 or 10頭あたりにリリース予定です。
// AlterCheck (ドキュメントも全面的にリニューアルしました、ぜひご覧あれ)
http://dbflute.seasar.org/ja/manual/function/generator/task/replaceschema/altercheck.html
DBFlute Engineの該当部分のソースコードはこちらです。
DfUnreleasedAlterAgentクラスに集約されています。
https://github.com/dbflute/dbflute-core/blob/mission_20190912_altercheck_parallelly/dbflute-engine/src/main/java/org/dbflute/logic/replaceschema/process/altercheck/agent/DfUnreleasedAlterAgent.java
最終的に以下のような形になっています。
(ただ、unreleased-checked-alterのディレクトリ名とか、
READONLY_のprefixはフィードバック次第でまだ変わる可能性あり)
```
playsql
|-data // ReplaceSchemaの登録データのディレクトリ
|
|-migration // AlterCheck用のディレクトリのトップ
| |
| |-alter // AlterDDLを書くディレクトリ (一時作業領域なのでgitignore推奨)
| | |-alter-schema.sql
| | |-alter-schema-[チケット番号].sql
| |
| |-history // AlterCheckのSQLファイルの履歴ディレクトリ
| | |-[日付]
| | | |-[日時]
| | | | | // 本番DBにリリース済みのAlterDDL
| | | | |-finished-alter...zip // (用済みなのでgitignoreでもOK)
| | | |
| | | |-[日時]
| | | | // 未リリースでチェック済みのAlterDDL @until DBFlute-1.2.0
| | | |-checked-alter...zip
| | |
| | | // 未リリースでチェック済みのAlterDDL @since DBFlute-1.2.0
| | |-unreleased-checked-alter
| | |-DONT_EDIT_HERE.dfmark
| | |-for-previous-20120804-1746.dfmark
| | |-READONLY_alter-schema.sql
| | |-READONLY_alter-schema-[チケット番号].sql
| |
| |-previous // SavePrevious用のディレクトリ
| | |-previous-20120804-1746.zip // 前のDBを再現するPreviousDDL
| |
| |-schema // 様々なスキーマ情報のディレクトリ
| | |-alter-check-result.html // チェック結果が記載されているHTML
```
※スプリントまたがりのすれ違いに関しては、特に何も対応しないことにしました。
対応が難しいのと、対応する必要もあまりないだろうということで割り切っています。
AlterCheckリニューアル、実装とドキュメント修正だけ終わりました。
これからRC版で現場で試してもらって、最終的に9末 or 10頭あたりにリリース予定です。
// AlterCheck (ドキュメントも全面的にリニューアルしました、ぜひご覧あれ)
http://dbflute.seasar.org/ja/manual/function/generator/task/replaceschema/altercheck.html
DBFlute Engineの該当部分のソースコードはこちらです。
DfUnreleasedAlterAgentクラスに集約されています。
https://github.com/dbflute/dbflute-core/blob/mission_20190912_altercheck_parallelly/dbflute-engine/src/main/java/org/dbflute/logic/replaceschema/process/altercheck/agent/DfUnreleasedAlterAgent.java
最終的に以下のような形になっています。
(ただ、unreleased-checked-alterのディレクトリ名とか、
READONLY_のprefixはフィードバック次第でまだ変わる可能性あり)
```
playsql
|-data // ReplaceSchemaの登録データのディレクトリ
|
|-migration // AlterCheck用のディレクトリのトップ
| |
| |-alter // AlterDDLを書くディレクトリ (一時作業領域なのでgitignore推奨)
| | |-alter-schema.sql
| | |-alter-schema-[チケット番号].sql
| |
| |-history // AlterCheckのSQLファイルの履歴ディレクトリ
| | |-[日付]
| | | |-[日時]
| | | | | // 本番DBにリリース済みのAlterDDL
| | | | |-finished-alter...zip // (用済みなのでgitignoreでもOK)
| | | |
| | | |-[日時]
| | | | // 未リリースでチェック済みのAlterDDL @until DBFlute-1.2.0
| | | |-checked-alter...zip
| | |
| | | // 未リリースでチェック済みのAlterDDL @since DBFlute-1.2.0
| | |-unreleased-checked-alter
| | |-DONT_EDIT_HERE.dfmark
| | |-for-previous-20120804-1746.dfmark
| | |-READONLY_alter-schema.sql
| | |-READONLY_alter-schema-[チケット番号].sql
| |
| |-previous // SavePrevious用のディレクトリ
| | |-previous-20120804-1746.zip // 前のDBを再現するPreviousDDL
| |
| |-schema // 様々なスキーマ情報のディレクトリ
| | |-alter-check-result.html // チェック結果が記載されているHTML
```
※スプリントまたがりのすれ違いに関しては、特に何も対応しないことにしました。
対応が難しいのと、対応する必要もあまりないだろうということで割り切っています。
jflute
Sep 17, 2019, 8:13:41 AM9/17/19
to DBFluteユーザの集い
jfluteです
一つ前のメール、構造でひとつ間違いがありました。
unreleased-checked-alter の中に DONT_EDIT_HERE.dfmark や、
READONLY_alter-schema.sqlが入ります。
以下が正しいです。
```
playsql
|-data // ReplaceSchemaの登録データのディレクトリ
|
|-migration // AlterCheck用のディレクトリのトップ
| |
| |-alter // AlterDDLを書くディレクトリ (一時作業領域なのでgitignore推奨)
| | |-alter-schema.sql
| | |-alter-schema-[チケット番号].sql
| |
| |-history // AlterCheckのSQLファイルの履歴ディレクトリ
| | |-[日付]
| | | |-[日時]
| | | | | // 本番DBにリリース済みのAlterDDL
| | | | |-finished-alter...zip // (用済みなのでgitignoreでもOK)
| | | |
| | | |-[日時]
| | | | // 未リリースでチェック済みのAlterDDL @until DBFlute-1.2.0
| | | |-checked-alter...zip
| | |
| | | // 未リリースでチェック済みのAlterDDL @since DBFlute-1.2.0
| | |-unreleased-checked-alter
| | | |-DONT_EDIT_HERE.dfmark
| | | |-for-previous-20120804-1746.dfmark
| | | |-READONLY_alter-schema.sql
| | | |-READONLY_alter-schema-[チケット番号].sql
| |
| |-previous // SavePrevious用のディレクトリ
| | |-previous-20120804-1746.zip // 前のDBを再現するPreviousDDL
| |
| |-schema // 様々なスキーマ情報のディレクトリ
| | |-alter-check-result.html // チェック結果が記載されているHTML
```
| |-previous // SavePrevious用のディレクトリ
| | |-previous-20120804-1746.zip // 前のDBを再現するPreviousDDL
| |
| |-schema // 様々なスキーマ情報のディレクトリ
| | |-alter-check-result.html // チェック結果が記載されているHTML
```
2019年9月15日日曜日 19時56分53秒 UTC+9 jflute:
kubo
Oct 3, 2019, 2:56:22 AM10/3/19
to DBFluteユーザの集い
jfluteです
[Request]Windowsマシンをお持ちの方へ、お願いがあります。
AlterCheckのリニューアルの実装ができたので、
Windows環境で以下のテストを行って頂けないでしょうか？
単純に「やったよ、だいじょうぶそうだよ」っていうレベルで良いです。
不安なのは、unreleased-checked-alterディレクトリ関連のファイル制御です。
ちゃんとコピー・移動できてるか？renameできているか？あたりの挙動をWindowsで確認したいです。
```
// AlterCheck
http://dbflute.seasar.org/ja/manual/function/generator/task/replaceschema/altercheck.html
(0. dbflute-test-active-hangarプロジェクトをgit clone)
=> https://github.com/dbflute-test/dbflute-test-active-hangar/
1. manage.bat save-previous
2. replace-schema-20-view.sql で TEST1_SUMMARY_PRODUCT を追加
=> viewのSQLはSUMMARY_PRODUCTのものをコピー (動けば何でも良い)
3. manage.bat alter-check
=> alter-check-result.htmlにはTEST1_SUMMARY_PRODUCTの差分だけが表示される
4. alter/alter-schema.sql に TEST1_SUMMARY_PRODUCT のcreate文をコピー
5. manage.bat alter-check
=> AlterCheckが成功する
=> alterディレクトリは空っぽになる
=> history/unreleased-checked-alter に READONLY_alter-schema.sql が作成される
=> READONLY_alter-schema.sql には TEST1 のcreateが入っている
6. replace-schema-20-view.sql で TEST2_SUMMARY_PRODUCT を追加
=> TEST1 のものをコピーして TEST2 にするだけ
7. manage.bat alter-check
=> TEST1のcreateが入った alter/alter-schema.sql が作成される
=> alter-check-result.htmlにはTEST2_SUMMARY_PRODUCTの差分だけが表示される
8. alter/alter-schema.sql に TEST2_SUMMARY_PRODUCT のcreate文をコピー
9. manage.bat alter-check
=> AlterCheckが成功する
10. manage.bat save-previous
=> unreleased-checked-alterディレクトリから、.sqlファイルがなくなる
=> history配下に日付ディレクトリで finished-alter...zip が作成される
=> そのzipの中に、TEST1, TEST2 の alter-schema.sql が入っている
```
[Request]Windowsマシンをお持ちの方へ、お願いがあります。
AlterCheckのリニューアルの実装ができたので、
Windows環境で以下のテストを行って頂けないでしょうか？
単純に「やったよ、だいじょうぶそうだよ」っていうレベルで良いです。
不安なのは、unreleased-checked-alterディレクトリ関連のファイル制御です。
ちゃんとコピー・移動できてるか？renameできているか？あたりの挙動をWindowsで確認したいです。
```
// AlterCheck
http://dbflute.seasar.org/ja/manual/function/generator/task/replaceschema/altercheck.html
(0. dbflute-test-active-hangarプロジェクトをgit clone)
=> https://github.com/dbflute-test/dbflute-test-active-hangar/
1. manage.bat save-previous
2. replace-schema-20-view.sql で TEST1_SUMMARY_PRODUCT を追加
=> viewのSQLはSUMMARY_PRODUCTのものをコピー (動けば何でも良い)
3. manage.bat alter-check
=> alter-check-result.htmlにはTEST1_SUMMARY_PRODUCTの差分だけが表示される
4. alter/alter-schema.sql に TEST1_SUMMARY_PRODUCT のcreate文をコピー
5. manage.bat alter-check
=> AlterCheckが成功する
=> alterディレクトリは空っぽになる
=> history/unreleased-checked-alter に READONLY_alter-schema.sql が作成される
=> READONLY_alter-schema.sql には TEST1 のcreateが入っている
6. replace-schema-20-view.sql で TEST2_SUMMARY_PRODUCT を追加
=> TEST1 のものをコピーして TEST2 にするだけ
7. manage.bat alter-check
=> TEST1のcreateが入った alter/alter-schema.sql が作成される
=> alter-check-result.htmlにはTEST2_SUMMARY_PRODUCTの差分だけが表示される
8. alter/alter-schema.sql に TEST2_SUMMARY_PRODUCT のcreate文をコピー
9. manage.bat alter-check
=> AlterCheckが成功する
10. manage.bat save-previous
=> unreleased-checked-alterディレクトリから、.sqlファイルがなくなる
=> history配下に日付ディレクトリで finished-alter...zip が作成される
=> そのzipの中に、TEST1, TEST2 の alter-schema.sql が入っている
```
taknb2nch
Oct 3, 2019, 9:33:39 PM10/3/19
to dbf...@googlegroups.com
taknb2nchです。
Windows10Pro、Java8、コマンドプロンプトからの実行の環境で動作を確認してみました。
手順書通りに問題なく動作しているように思います。
以下、手順10が完了した時点のディレクトリ構成です。
.\DBFLUTE_MAIHAMADB\PLAYSQL\MIGRATION
│ .gitignore
│ previous-OK.dfmark
│
├─alter
├─history
│ ├─201910
│ │ └─20191004_1021
│ │ finished-alter-to-20191004-0957.zip
│ │
│ └─unreleased-checked-alter
│ DONT_EDIT_HERE.dfmark
│
├─previous
│ │ previous-20191004-1021.zip
│ │
│ └─data
│ ├─common
│ │ └─xls
│ └─ut
│ ├─csv
│ │ └─UTF-8
│ ├─mail
│ ├─tsv
│ │ └─UTF-8
│ │ └─mail
│ └─xls
└─schema
└─craftdiff
以上、よろしくお願いいたします。
Windows10Pro、Java8、コマンドプロンプトからの実行の環境で動作を確認してみました。
手順書通りに問題なく動作しているように思います。
以下、手順10が完了した時点のディレクトリ構成です。
.\DBFLUTE_MAIHAMADB\PLAYSQL\MIGRATION
│ .gitignore
│ previous-OK.dfmark
│
├─alter
├─history
│ ├─201910
│ │ └─20191004_1021
│ │ finished-alter-to-20191004-0957.zip
│ │
│ └─unreleased-checked-alter
│ DONT_EDIT_HERE.dfmark
│
├─previous
│ │ previous-20191004-1021.zip
│ │
│ └─data
│ ├─common
│ │ └─xls
│ └─ut
│ ├─csv
│ │ └─UTF-8
│ ├─tsv
│ │ └─UTF-8
│ └─xls
└─schema
└─craftdiff
以上、よろしくお願いいたします。
2019年10月3日(木) 15:56 kubo <dbf...@gmail.com>:
--
このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには dbflute+u...@googlegroups.com にメールを送信してください。
このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msgid/dbflute/CAALfU-AoP-w%2BgnY8%3DuxWGUM_iESHqRbuiNy%2BQhLYeC38EWT_0A%40mail.gmail.com にアクセスしてください。
kubo
Oct 3, 2019, 11:12:37 PM10/3/19
to DBFluteユーザの集い
jfluteです
taknb2nchさん、こんにちは
> Windows10Pro、Java8、コマンドプロンプトからの実行の環境で動作を確認してみました。
> 手順書通りに問題なく動作しているように思います。
おおー、めっちゃありがとうございます！
丁寧にディレクトリ構成まで共有、本当に助かります。
※ああ、良かったぁ、動いたぁ(^^
taknb2nchさん、こんにちは
> Windows10Pro、Java8、コマンドプロンプトからの実行の環境で動作を確認してみました。
> 手順書通りに問題なく動作しているように思います。
おおー、めっちゃありがとうございます！
丁寧にディレクトリ構成まで共有、本当に助かります。
※ああ、良かったぁ、動いたぁ(^^
Reply all
Reply to author
Forward
0 new messages