【15】AtoMの再インストール

今日はストレス解消から始めます！
つまり、前回狂ったAtoMを壊すぞ〜〜〜〜　イェ〜

設定は残したまま（？）、AtoMとデータベースをすべて削除します。
その後、
１）AtoMを再インストール
２）データベースをクリエートします。
https://www.accesstomemory.org/ko/docs/2.4/admin-manual/installation/linux/ubuntu-xenial/

でも、削除するのはエンターを押したらあっという間で、全然ストレス解消になりませんでした。　^^;

AtoMの設定が完了したら以下の設定を追加します。
１）言語に日本語を追加
２）pluginを全部インストール

まず、exampleのCSVを入れて動作を確認します。
ubuntuのマシン（サーバー）でexportします。
exportしたもののタイトルだけを変更して、変更が反映されるか試します。

ここで、また前回からの続きの問題にぶつかりました。
exportしたCSVへ追記を行う際にもとのフォンドを同定する条件に関する問題です。

どうも、Legacy IDは複数あるという話が。（え？）
なぜかというと、import時に設定したLegacyIDと、export時に出てくるLagacyIDが異なることに気づいたのです。どうもexport時のLegacyIDはjob番号のよう。
しかし、LegacyIDは所蔵先が入れるものでコントロールするものじゃなかったっけ？

ここで、永遠と続く実験の世界に入り込んでしまったわけでして…（ーー；）
若干場当たり的な実験が続きますが、お付き合いくださいまし。

１）
CSVのLagacyIDに3000を入れてimportしてみる。
それをexportして、3000が残っているかを確認します。
3000は残ってない。
やはりexportしたCSVのLegacyIDはAtoMのjob番号が付与されているよう。

２）
最初importしたCSV（マッチング条件LegacyID、source nameを満足）のタイトルを変えてから再度importしてみる。
結果が…思いつかない…　T..T

３）
exportしたもののタイトルを変えて、delete matching and replace... をオプションにすると、変更が反映された。しかし、それをexportすると、legacyIDが変更された。これは完全に削除してから新しく書き換えているので、LagacyIDも新しいjob番号が付与された模様。deleteは、親（Fond)が合えば下は自動で全部消える設定になっている(マニュアルにそう書いてあるよ〜）。

４）
exportしたCSVのマッチングさせるための2つの条件と関係ない項目を変更して、もう一度実験。タイトルはマッチするかの判断の2番目の条件になっているので、そこが変わるとマッチしてないと判断している可能性があるように思われる。
予感は的中した。アップデートに成功。
つまり、タイトルを判断基準にしているようだ。

５）
６）
・
・
・

何度か実験は続きましたが、条件をどう変更したか、結果がどうなったか覚えられなくなりました。（頭の限界です〜　(^^)a　）

しかし、今日の発見は、マッチングの条件
１）legacy ID, source name
２）title, identifier, repository
の考えられる組み合わせで実験してみると、DIPへの追記のコツがわかりそうだと言うことでした。

現在、CSVに追記してimportした時に該当部分が変更されるのではなく、変なアイテムが追加されちゃったり、階層が狂って追加されたりする現象をなくすためにも、これは確認する価値があるかもしれません。

ということで、今日はここまでです。
ガソリンも2倍注入して、かなり遅くなりました。
若干くたびれたけど、次回も頑張りましょうね。

========================================
次回は、引き続き謎解きに挑戦し、コツが分かったらDIPをAtoMへuploadします〜