Data migration of documents to S3 fails with NoSuchFileVersionException

問題

FileSystemStoreからS3へのドキュメント・ライブラリの移行には、データ移行ツールを使用しています。
実行中、NoSuchFileVersionException で失敗します（完全なエラー・スタック・トレースについては添付ファイルを参照してください）。

環境

解像度

マイグレーションプロセスがアダプティブメディアのエントリを処理中に失敗するのは、おそらく、dlfileversionテーブルに存在しないfileversionidを持つエントリ(amimageentryテーブル内)に遭遇するためです。

以下のようなセレクトをすれば、本当にそのような孤児記録があるのか、またその数はどのくらいなのかがわかるはずだ：
```
select count(*) from amimageentry where fileversionid not in (select fileversionid from dlfileversion);
```
あるいは、詳しく見ることができる：
```
select * from amimageentry where fileversionid not in (select fileversionid from dlfileversion);
```
移行前のデータベースで、これらが何を返すか確認するとよいだろう。
以上のことから、これが起こっていることであることが確認できたと仮定して、それに関する詳細情報は以下を参照してください。
https://issues.liferay.com/browse/LPS-114817.
要約すると、この修正が導入される前は、エンドユーザが古いバージョンのドキュメントを削除する場合、そのドキュメントのアダプティブメディアのプレビューとサムネイルは削除されませんでした(データベース - amimageentryテーブルからも、ファイルシステムからも)。だから、これらの孤児となったエントリーはそこに残された。
この問題を解決するために作られたGroovyスクリプトが添付されている。使用する前によく読んでください。重要な説明や指示が書かれていますが、ここでも要約してみます：
- デフォルトでは、このスクリプトはいわゆるセーフモードで実行されます（最後の_safeMode = true変数を参照してください）。最後に、すべての準備が整い、考え抜いたら、スクリプト内で_safeMode変数をfalseに設定し、スクリプトを再度実行する。この時、実際にデータベースから孤児ファイルが削除されます。
- このスクリプトは、 amimageentry テーブルから孤児となったデータベースエントリを削除するだけで、ファイルシステム内の対応するファイル/フォルダを削除することはできません。ファイルシステムからファイルを手動で削除する方法については、スクリプトの冒頭で説明しています。しかし、ファイルシステムから手動でフォルダを削除することは必ずしも必要ではありません。なぜなら、もし（クリーンアップスクリプトを実行した後）それらのオーファンエントリがデータベースにもう存在しないのであれば、データ移行プロセスはそれらに遭遇しないので、おそらくそれらについて何もしないでしょうし、ファイルシステム内の対応するオーファンファイルについても何もしないでしょうから、S3バケットにそれらを転送することもないでしょう。つまり、データ移行プロセスは、単にそれらの孤児ファイルを無視し、S3バケット内の新しい "ファイルシステム "にそれらを転送しないことによって、ファイルシステムのクリーンアップの一部をあなたのために行います。従って、スクリプトを実行し（孤児となったデータベース・エントリーを削除する）、データ移行を再度行えば十分だと思います。
- スクリプトは7.2用に書かれていますが、7.4でも動作するはずです。

ドキュメントのS3へのデータ移行がNoSuchFileVersionExceptionで失敗する

問題

環境

解像度