マニュアルより
- legacy idに関する記述が以下にあり
- https://www.accesstomemory.org/en/docs/2.4/user-manual/import-export/csv-import/#legacy-id-mapping-dealing-with-hierarchical-data-in-a-csv
- 上のリンク先の第2パラグラフに、「legacy ID」は「source_id」という名前でデータベースに登録されます。確認したい人はコマンドラインか、phpMyAdmin等のツールを使ってね、と記述あり。
- atomのインタフェースからは確認できない模様
- ということで、csvでインポートする際のlegacy IDは覚えておく必要あり(忘れた場合の対処法は後述)
- やはり、登録時のlegacy IDをキーとして、Update時におけるマッチ判定をしていそう
- phpMyAdmin等のツールを使ってデータベースを覗けば確認できるということで、確認してみた。

- 上記はサンプルデータ(legacy IDが「1」と「2」)をインポートしてみた結果
- 確かにlegacy IDの値はsource_idとして登録されており、またエクスポート時に出現するjob idに基づいて与えられるid(4XXや5XX)は、target_idとして格納されている
- legacy IDを忘れてしまっても、上記のテーブルを参照すれば、再現可能
検証環境(Amazon AWS)
試行錯誤の内容
1.「Example_information_objects_isad-2.3.csv」をインポート
a. 2行(1フォンド、1アイテム)
b. legacy IDは「1」と「2」
c.
2. 1をAtoMからエクスポート
a. ファイル名は「isad_0000000001.csv」
b. 2行(1フォンド、1アイテム)aaaa
c. legacy IDは「446」「469」
3. 2でエクスポートしたファイルを「Example_information_objects_isad-2.3.csv」にRenameしてインポート
a. ファイル名は「Example_information_objects_isad-2.3.csv」
b. 2行(1フォンド、1アイテム)
c. legacy IDは「446」「469」
d. オプションは「create」
e. 結果、2行(1フォンド、1アイテム)が新規に登録される
f.
g. 【わかったこと】legacy IDがsource_idとして登録される。
4.(質問への回答)source_idが469(target_id:497)の親Fondsを他のFondsにatomのインタフェース上で変更
a. 結果、parentIdのみ変更される
b.
c.【わかったこと】親子関係が変わっても、source_id(legacy id)やtarget_idは変わらない => atomのUI上で親子関係を変更しても問題なさそう
5. 1でインポートしたcsvを「name_changed.csv」に変更し、インポート
a. ファイル名は「name_changed.csv」
b. 2行(1フォンド、1アイテム)
c. legacy IDは「1」「2」
d. オプションは「create」
e. 結果、2行(1フォンド、1アイテム)が新規に登録される
f.
g.【わかったこと】legacy idは重複し得る。
6. 5のcsvのタイトルを変更してUpdate
a.

b. ファイル名は「name_changed.csv」
c. 2行(1フォンド、1アイテム)
d. legacy IDは「1」「2」
e. タイトルは「abd」「def」
f. オプションは「update」
g. 結果、 5で登録された2行(1フォンド、1アイテム)のみ更新される
h.

i.【わかったこと】legacy idが重複した場合はsource_nameが一致するもののみアップデートされる。
ここまでの考え
csv export時のlegacy ID(= keymapテーブルにおけるtarget_id)は意味なさそう
=> これがupdate時のマッチング判定には使われなさそう。やはり import時のlegacy ID(= keymapテーブルにおけるsource_id)が重要そう。
引き続き要検討です。
- atomのインタフェースからは確認できない模様
- ということで、csvでインポートする際のlegacy IDは覚えておく必要あり(忘れた場合の対処法は後述)
- やはり、登録時のlegacy IDをキーとして、Update時におけるマッチ判定をしていそう
- 上記はサンプルデータ(legacy IDが「1」と「2」)をインポートしてみた結果
- 確かにlegacy IDの値はsource_idとして登録されており、またエクスポート時に出現するjob idに基づいて与えられるid(4XXや5XX)は、target_idとして格納されている
- legacy IDを忘れてしまっても、上記のテーブルを参照すれば、再現可能