propel-load-data で読み込みが失敗するケース。
varchar や longvcarcher の要素に、特定のモノが入っていると、正常にロードできない。
propel-dump-data で出力したデータでも、この事情は考慮されない。
つまり、propel-dump-data -> propel-load-data の処理で元に戻らないことがある。
ケース1
データの内容が yaml 形式。
文字列の要素に yaml 形式のものを入れてはいけない。
可読性が問題ではないなら、配列にして serialize / unserialize するとよい。
ケース2
varchar で、指数表記と勘違い。
46e72917 のような文字列が入っていると、46 の 72917 乗で処理しようとする。
この場合、オーバーフローするので文字列に INF がセットされる。
918193e7 のような場合だと 9.18193E+12 になる。
パスワードなど、ランダムな文字列を生成している場合、注意が必要。
ケース3
複数行のデータで行頭に # がある。
スタイルシートをデータに入れている場合、要注意。
タグ要素を指定するなりして # が先頭に来ないようにして対応。
varchar や longvcarcher の要素に、特定のモノが入っていると、正常にロードできない。
propel-dump-data で出力したデータでも、この事情は考慮されない。
つまり、propel-dump-data -> propel-load-data の処理で元に戻らないことがある。
ケース1
データの内容が yaml 形式。
文字列の要素に yaml 形式のものを入れてはいけない。
可読性が問題ではないなら、配列にして serialize / unserialize するとよい。
ケース2
varchar で、指数表記と勘違い。
46e72917 のような文字列が入っていると、46 の 72917 乗で処理しようとする。
この場合、オーバーフローするので文字列に INF がセットされる。
918193e7 のような場合だと 9.18193E+12 になる。
パスワードなど、ランダムな文字列を生成している場合、注意が必要。
ケース3
複数行のデータで行頭に # がある。
スタイルシートをデータに入れている場合、要注意。
タグ要素を指定するなりして # が先頭に来ないようにして対応。
コメントする