atomにおけるcsvインポート（アップデート）について

マニュアルより

• 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）

試行錯誤の内容
１．「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）が重要そう。
引き続き要検討です。

7. 3のcsvのファイル名とタイトルを変更してUpdate
  a.


  b. ファイル名は「名前変更.csv」
  c. 2行（1フォンド、1アイテム）
  d. legacy IDは「446」「469」
  e. タイトルは「source_nameとtitleを変えてみた。legacy idは登録時のものを参照。」「source_nameとtitleを変えてみた。legacy idは登録時のものを参照。」
  f. オプションは「update」
  g. 結果、 新たに2行（1フォンド、1アイテム）が追加される
  h.
  i. 【わかったこと】legacy idが一致しても、source nameかつtitleが違う場合にはマッチ判定されない。
       ①第一条件：legacy idは一致するが、source nameが異なるため、第一条件の
          マッチ判定は通らない
       ②第二条件：title, repository name, identifierの一致を見るが、titleが異なるため
          マッチ判定は通らない
       ③結果：新規に追加される

8. 7のcsvをベースとして、ファイル名（source_name）とlegacy id（source_id）を維持した上で、タイトルのみを変更してみた
  a. ファイル名は「名前変更.csv」
  b. 2行（1フォンド、1アイテム）
  c. legacy IDは「446」「469」
  d. タイトルは「Legacy idとsource_nameを維持した上で、titleだけ変えてみた
     fonds.」「Legacy idとsource_nameを維持した上で、titleだけ変えてみたitem.」
  e.オプションは「update」
  f. 結果、7でインポートした2つのタイトルが更新された。
  g. わかったこと】タイトル（or repository or identifier）を変更したい場合には、
      source_id（インポート時のlegacy id）とsource_name（csvファイル名）を揃える
      必要ありそう

(END)

【16】DIPをAtoMへ登録してからCSVを利用してupdate

風が強くて華奢な女子大生は飛ばされるのではないかと思える天気でしたが、横に増えつつある中年女性は飛ばされる心配もなく、無事道場に着きました。（@^^@)

ですが、今日は参加者が少ない。（皆どうしたんだよ〜〜）

でも、いつものようにガソリンを入れて始めます！

皆を待ちながらしばし議論〜

archivemeticaからAtoMまでの流れを今一度説明するYo!
（ホワイトボードに何か書くYo!)

やはり、exportした時のLegacy IDは、データ更新のときにはあまり気にしないで、もとのLegacy IDを管理するのが正しいのではという話をしました。

そうすると…

DIPにはLegacy IDがない。どうするんだ？　

これがずっと前から悩んでいた問題でした。

さてさて、いつものように結論はなし！
問題を再確認したところで次に進みます。

===============================

今日は久しぶりにArchivemeticaからDIPを作ります！

久しぶりなので、やはりエラーがでました。

我々の期待を裏切らない機械です。

でもなんとかDIPをAtoMに入れました。

そのCSVをexportします。

Legacy IDが付与されて出てきましたが、このLegacy IDを利用して
記述をupdateすると新しくデータが登録されてしまいます。

だから〜DIPで入れたもののLegacy IDを確認するしかないってこと？
（これは面倒だ・・・）

少し紛らわしいので、ここでは元のLegacyIDを元（もと）ちゃん、export時に出てくるLegacy IDを偽ちゃんと呼ぶことにしましょう。

ここで、カッコいいエンジニアの出番です！　シャキ─（σ｀・∀・´）σ

コマンドモードから、keymapテーブルを探し、その中身を確認します。
そこには、source_id, target_id, source_nameが記録されています。

なんと！keymapテーブルでは、偽ちゃんがtarget_idになっていて、それに対応するsource_id（これが元ちゃん）が確認できました。DIPで入れたものでも、元ちゃんが存在するのです。updateに使うLegacy IDは、もちろんここにある元ちゃんということになるのでしょうか。

ではでは、確認した元ちゃんをCSVのLegacy IDとして入力し、タイトルだけを変えてみます。そしてupdate～～～

そうすると、なんとうまくupdateされました！
（ここまでの道のりは長かった…　ITに弱い人間が生きていくのは大変です…）

ここでもう一つ発見！
偽ちゃんは意味のないように思えましたし、なぜそんなものが出てくるのか、ずっと疑問でした。まぎらわしいし、なぜそんなことをする必要があるのか…
予想ではありますが、この偽ちゃんを利用するれば、大量のデータを更新できそうな気がしました。つまり、CSVの偽ちゃんに対応する元ちゃんを探して、自動で入れ替えるプログラムを組めば、機械で処理ができます。

また、色々実験した結果、元ちゃんとsource_nameは重複して存在し得ることがわかりました。しかし、target_idは重複しません。なのでtarget_idがデータベース上で、唯一の識別idとして機能しているのはと思われます。

色々実験した結果、元ちゃんと偽ちゃんに関する理解は少し深まりました。
道場での実験に加えて、メンバーによる個別実験が行われました。
これについては以下の記事を参考にしてください。
https://irisawadojo.blogspot.com/2018/08/atomcsv.html
http://irisawadojo.blogspot.com/2018/07/atomcsvupdate.html

最終的に、わかったことを以下簡単に整理します。

1. KeymapにはLegacy IDがsource_idとして登録される。
2. 親子関係が変わっても、source_idとtarget_idは変わらない。
3. Legacy IDは重複し得る。
4. まったく同じファイルを2回登録すると、target_idのみ異なる。
5. まったく同じファイルを登録した場合は、最新のものが更新される。
6. Legacy IDが重複した場合、source nameが一致するもののみアップデートされる。
7. CSV export時のLegacy ID（kepmapテーブルにおけるtarget_idは更新時のマッチング判定にはつかわれなさそう。（ほかに、Legacy IDが異なるが同じものであることの判定や、Legacy IDとsource_nameが同一であるが異なるものであることの判定などに使われている？）

今日は通常より短めの作業でしたが、一歩進みましたので良い気分で終わります！

• ｡(￣∇￣*)oｸﾞｯﾄﾞ!!d(*￣∇￣)｡

========================
皆気分がよくて、次回やること話すの忘れました。（^^;)

AtoMのCSVによるupdate条件の実験

CSVを利用して、すでにある記述をupdateする際のマッチング条件

・第一条件：Legacy IDとsource_nameがマッチングすればupdate

・第二条件：第一条件を満足しなければ、tilte, repository, identifierがマッチングすればupdate

以下は実験による、kepmapテーブルの変化

kepmapテーブルでは、Legacy ID はsource_idと同一で、target_idはexport時に自動で付与されて出てくるLegacy IDと同一。

実験①
画面キャプチャーなし

実験②
画面キャプチャーなし

実験③
Legacy ID、source_nameが異なり、title、repository, identifierが同じ場合
データは問題なく更新され、keymapには新しいsource_idに元のtarget_idが付与された。

以下keymapテーブルのキャプチャー画面（phpMyAdminを利用）

※同じファイルを2回createした時
Source_idは同一で、target_idが新しく付与される。
タイトルだけを変えてデータを更新してみると、後で登録したフォンド（target_idが947,962）だけが更新された。

以上