Closed Juha42 closed 5 years ago
Olen nyt implementoinut tämän. Tarjokasaineistoja voi poistaa käyttäjän "profiilisivulta" /settings ja myös Gramps-tiedostojen listasta sivulta /gramps/uploads. Jälkimmäisessä sen voi tehdä vain jos vastaava .gramps-tiedosto on edelleen palvelimella. Koodi poistaa tietokannasta kaikki ko. Batch-noodin osoittamat noodit (b:Batch{id:$batch_id}) -[*]-> (a) sekä myös päivittää .gramps.meta-tiedostoa, jos sellainen on uploads-hakemistossa.
Toteutuksesta puuttuu vielä käännöstekstit suomeksi ym. Ja voihan siinä olla virheitäkin, kun en ole ihan varma etteikö tuo Cypher-lause poistaisi jotain ylimääräistäkin!?
Joo, poistaa se ylimääräistä, koska henkilö ym. voi kuulua useampaan tarjokasaineistoon. Pitää kai korjata niin että batchin poistaminen poistaa vain sellaiset solmut, joihin ei ole viittauksia muista batcheistä tms.
Ei pitäisi minkään henkilön tai tapahtuman kuulua useaan tarjokasaineistoon. Mutta työ on sikäli kesken, että ehkä lähteitä ja paikkoja voi olla vielä yhteisenä. -- Juha Lähetetty kännykästä K-9 Maililla
Joo, poistaa se ylimääräistä, koska henkilö ym. voi kuulua useampaan tarjokasaineistoon. Pitää kai korjata niin että batchin poistaminen poistaa vain sellaiset solmut, joihin ei ole viittauksia muista batcheistä tms.>
-- > You are receiving this because you are subscribed to this thread.> Reply to this email directly or view it on GitHub:> https://github.com/Taapeli/stk-upload/issues/9#issuecomment-509287315
Arvelin että jos saman gramps-puun lataa moneen kertaan (esim sibeliuksen eri versioita) niin henkilöitä, joilla on sama handle, ei duplikoida vaan pannaan molemmat batch-nodet osoittamaan samaan person-nodeen...?
Sitä handlea ei käytetä avaimena muuta kuin tarjokasaineistoon sisäisen rakenteen toteuttamiseen. Handlen käyttötarkoituksesta on keskusteltu tuloksetta eikä muuta tarkoitusta ole ilmennyt.
Ps. Eikös Jormakin pitäisi olla jakelussa, xml-tuonti on hänen rakentamansa systeemi -- Juha Lähetetty kännykästä K-9 Maililla
Arvelin että jos saman gramps-puun lataa moneen kertaan (esim sibeliuksen> eri versioita) niin henkilöitä, joilla on sama handle, ei duplikoida vaan> pannaan molemmat batch-nodet osoittamaan samaan person-nodeen...?>
ti 9. heinäk. 2019 klo 14.46 Juha notifications@github.com kirjoitti:>
Ei pitäisi minkään henkilön tai tapahtuman kuulua useaan> tarjokasaineistoon. Mutta työ on sikäli kesken, että ehkä lähteitä ja> paikkoja voi olla vielä yhteisenä.> -- Juha> Lähetetty kännykästä K-9 Maililla>
- heinäkuuta 2019 19.01.49 GMT+03:00 kkujansuu notifications@github.com> kirjoitti:> Joo, poistaa se ylimääräistä, koska henkilö ym. voi kuulua useampaan> tarjokasaineistoon. Pitää kai korjata niin että batchin poistaminen> poistaa vain sellaiset solmut, joihin ei ole viittauksia muista> batcheistä tms.>>
-- >> You are receiving this because you are subscribed to this thread.>> Reply to this email directly or view it on GitHub:>>
https://github.com/Taapeli/stk-upload/issues/9#issuecomment-509287315>
—> You are receiving this because you commented.> Reply to this email directly, view it on GitHub>
https://github.com/notifications/unsubscribe-auth/AEIYOXVHJTA6SGS3AGMBL43P6R3CBANCNFSM4H5FMMOQ> .>
-- > You are receiving this because you commented.> Reply to this email directly or view it on GitHub:> https://github.com/Taapeli/stk-upload/issues/9#issuecomment-509613320
Tämähän on Github Issues -säie, mutta kai tähän näin voi ottaa Jormankin mukaan.
ti 9. heinäk. 2019 klo 20.27 Juha (notifications@github.com) kirjoitti:
Sitä handlea ei käytetä avaimena muuta kuin tarjokasaineistoon sisäisen rakenteen toteuttamiseen. Handlen käyttötarkoituksesta on keskusteltu tuloksetta eikä muuta tarkoitusta ole ilmennyt.
Ps. Eikös Jormakin pitäisi olla jakelussa, xml-tuonti on hänen rakentamansa systeemi -- Juha Lähetetty kännykästä K-9 Maililla
- heinäkuuta 2019 14.59.34 GMT+03:00 kkujansuu notifications@github.com kirjoitti:
Arvelin että jos saman gramps-puun lataa moneen kertaan (esim sibeliuksen> eri versioita) niin henkilöitä, joilla on sama handle, ei duplikoida vaan> pannaan molemmat batch-nodet osoittamaan samaan person-nodeen...?>
ti 9. heinäk. 2019 klo 14.46 Juha notifications@github.com kirjoitti:>
Ei pitäisi minkään henkilön tai tapahtuman kuulua useaan> tarjokasaineistoon. Mutta työ on sikäli kesken, että ehkä lähteitä ja> paikkoja voi olla vielä yhteisenä.> -- Juha> Lähetetty kännykästä K-9 Maililla>
- heinäkuuta 2019 19.01.49 GMT+03:00 kkujansuu notifications@github.com> kirjoitti:> Joo, poistaa se ylimääräistä, koska henkilö ym. voi kuulua useampaan> tarjokasaineistoon. Pitää kai korjata niin että batchin poistaminen> poistaa vain sellaiset solmut, joihin ei ole viittauksia muista> batcheistä tms.>>
-- >> You are receiving this because you are subscribed to this thread.>> Reply to this email directly or view it on GitHub:>>
https://github.com/Taapeli/stk-upload/issues/9#issuecomment-509287315>
—> You are receiving this because you commented.> Reply to this email directly, view it on GitHub>
< https://github.com/Taapeli/stk-upload/issues/9?email_source=notifications&email_token=AEIYOXTZX7HNEWRAK5CXZS3P6R3CBA5CNFSM4H5FMMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQAMCI#issuecomment-509609481 ,> or mute the thread>
< https://github.com/notifications/unsubscribe-auth/AEIYOXVHJTA6SGS3AGMBL43P6R3CBANCNFSM4H5FMMOQ
.>
-- > You are receiving this because you commented.> Reply to this email directly or view it on GitHub:> https://github.com/Taapeli/stk-upload/issues/9#issuecomment-509613320
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Taapeli/stk-upload/issues/9?email_source=notifications&email_token=AEIYOXSFW5EYQLN4SBN3N2LP6TDBFA5CNFSM4H5FMMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQ6TQQ#issuecomment-509733314, or mute the thread https://github.com/notifications/unsubscribe-auth/AEIYOXR25WDE7T2ACDWBRMDP6TDBFANCNFSM4H5FMMOQ .
Näyttää siltä että jos saman aineiston lataa useampaan kertaan, niin neo4j-kantaan ei tule duplikaatteja henkilöitä, vaan jokaisesta Batch-noodista tulee relaatio samaan Person-nodeen. Sen sijaan ainakin Family-noodit luodaan jokaiseen tuontierään uudestaan. Tämä tuottaa vaikeuksia tuontierän poistamisessa: ko. Family-noodin voi poistaa mutta ei välttämättä Person-nodeja joihin siitä on linkit (vanhemmat, lapset), sillä he voivat kuulua johonkin toiseen tuontierään. Onko ehdotuksia ratkaisuksi?
Poistuuko ongelma, jos sisään tuotaessa luotaisiin tuplahenkilö? Miksisitä ei nyt luoda? Oleusarvoisestihan niitä ei pitäisi tuontierisä olla (montaa), ja jos on, niin tuplein yhdistelyn yhteydessä myös perhesuhteet pitää hoitaa ohdalleen.
-j
kkujansuu kirjoitti 11.7.2019 klo 12.40:
Näyttää siltä että jos saman aineiston lataa useampaan kertaan, niin neo4j-kantaan ei tule duplikaatteja henkilöitä, vaan jokaisesta Batch-noodista tulee relaatio samaan Person-nodeen. Sen sijaan ainakin Family-noodit luodaan jokaiseen tuontierään uudestaan. Tämä tuottaa vaikeuksia tuontierän poistamisessa: ko. Family-noodin voi poistaa mutta ei välttämättä Person-nodeja joihin siitä on linkit (vanhemmat, lapset), sillä he voivat kuulua johonkin toiseen tuontierään. Onko ehdotuksia ratkaisuksi?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Taapeli/stk-upload/issues/9?email_source=notifications&email_token=AMQQPZFZXCGALQGQMJHJ7N3P635ZTA5CNFSM4H5FMMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWER6I#issuecomment-510413049, or mute the thread https://github.com/notifications/unsubscribe-auth/AMQQPZDT7CO7WOTXCQFVNETP635ZTANCNFSM4H5FMMOQ.
-- -juha
Luulisi että ongelma poistuisi jos luotaisiin tuplahenkilö. Ylempänähän Juha sanoikin että "Ei pitäisi minkään henkilön tai tapahtuman kuulua useaan tarjokasaineistoon". Tässä vähän odotellaan kommenttia myös Jormalta, joka kai ko. koodin on kirjoittanut. Minusta näyttää siltä että tarkoitus on ollut ettei tuplaperheitäkään luotaisi, koska Cypher-lauseissa käytetään MERGE-verbiä (eikä CREATEa). Tämä on koodattu hieman eri tavalla Person ja Family-noodien yhteydessä. Tiedosto app/models/Cypher_gramps:
class Cypher_family_w_handle(): """ For Family class """
create_to_batch = """ MATCH (b:Batch {id: $batch_id}) MERGE (b) -[r:OWNS]-> (f:Family {handle: $f_attr.handle}) SET f = $f_attr RETURN ID(f) as uniq_id"""
class Cypher_person_w_handle(): """ For Person class """
create_to_batch = """ MATCH (b:Batch {id: $batch_id}) MERGE (p:Person {handle: $p_attr.handle}) MERGE (b) -[r:OWNS]-> (p) SET p = $p_attr RETURN ID(p) as uniq_id""
Koska relaatiot eri nodejen välille luodaan käyttäen ko. individin handle'a, niin materiaalin latauksessa luotaisiin relaatiot kaikkien tuplattujen saman handlen omaavien, esim. Person- ja Event-nodejen, välille.
Eli jos ensimmäisen latauksen jälkeen on henkilöllä P syntymätapahtuma E, niin uudelleen latauksen jälkeen sekä henkilöllä P että tuplatulla henkilöllä P2 on relaatiot sekä alkuperäiseen tapahtumaan E myös tuplattuun tapahtumaan E2.
Jotta lopputulos olisi oikein, niin latauksen jälkeen kaikkien ladattujen nodejen handlet pitäisi muuttaa/poistaa, jotta ne eivät sotkisi uudelleenlatausta.
jorma-h kirjoitti 11.7.2019 klo 14.38:
Koska relaatiot eri nodejen välille luodaan käyttäen ko. individin handle'a, niin materiaalin latauksessa luotaisiin relaatiot kaikkien tuplattujen saman handlen omaavien, esim. Person- ja Event-nodejen, välille.
Kyselen ehkä tyhmiä tai asiaan liittymättömiä, mutta... kyselen kuitenkin koska haluan oppia ymmärtämään tämän koneen logiikkaa...
1) Millä algoritmillä nämä handlet luodaan? Tuleeko eri tuontierissä taatustu uniikkeja vai taatusti samoja vai jotain siltä väliltä (=satunnisia, juoksevia, tms)?
Eli jos ensimmäisen latauksen jälkeen on henkilöllä P syntymätapahtuma E, niin uudelleen latauksen jälkeen sekä henkilöllä P että tuplatulla henkilöllä P2 on relaatiot sekä alkuperäiseen tapahtumaan E myös tuplattuun tapahtumaan E2.
2) Miksi syntyy P2 --> E?
3) Syntyykö myös P --> E2?
Jotta lopputulos olisi oikein, niin latauksen jälkeen kaikkien ladattujen nodejen handlet pitäisi muuttaa/poistaa, jotta ne eivät sotkisi uudelleenlatausta.
4) Eikös näistä handleista sanottu jossain että niitä käytetään vain aineiston sisään tuonnissa? Jos sen jälkeen ei tarvita, (vaan niistä näkyy olevan vain haittaa), eikä ne siinä tapauksessa jouda hävittää tuonnin lopuksi?
-j
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Taapeli/stk-upload/issues/9?email_source=notifications&email_token=AMQQPZALU2RW5HS7TJLWUDTP64LTTA5CNFSM4H5FMMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWNSUA#issuecomment-510450000, or mute the thread https://github.com/notifications/unsubscribe-auth/AMQQPZFWDUGPQDKYZCSTDWTP64LTTANCNFSM4H5FMMOQ.
-- -juha
Jotain vastauksia tyhmiin kysymykiini selviää oheisesta kuvasta, joka esittää neo-kannan sisältöä, kun kantaan on ladattu kolme eri tiedostoa, joista kaksi viimeistä on identtisiä keskenään (kopio). Molemmat tiedostot (kaksi ylintä ryhmää) esittävät omaa versiotani ankkojen laajasta sukukunnasta (tässä siis on vain pini osajoukko). Alempi isompi ryhmä on oikeita sukulaisiani (onneksi näistä ei ole syntynyt tuplia :-).
Vihreät pallot on Family, harmaat Person, siniset on Batch ja punaiset on Place. Oikeanpuoleinan Batch on jälkimmäinen lataus.
-j
Juha Takala kirjoitti 11.7.2019 klo 15.12:
jorma-h kirjoitti 11.7.2019 klo 14.38:
Koska relaatiot eri nodejen välille luodaan käyttäen ko. individin handle'a, niin materiaalin latauksessa luotaisiin relaatiot kaikkien tuplattujen saman handlen omaavien, esim. Person- ja Event-nodejen, välille.
Kyselen ehkä tyhmiä tai asiaan liittymättömiä, mutta... kyselen kuitenkin koska haluan oppia ymmärtämään tämän koneen logiikkaa...
1) Millä algoritmillä nämä handlet luodaan? Tuleeko eri tuontierissä taatustu uniikkeja vai taatusti samoja vai jotain siltä väliltä (=satunnisia, juoksevia, tms)?
Eli jos ensimmäisen latauksen jälkeen on henkilöllä P syntymätapahtuma E, niin uudelleen latauksen jälkeen sekä henkilöllä P että tuplatulla henkilöllä P2 on relaatiot sekä alkuperäiseen tapahtumaan E myös tuplattuun tapahtumaan E2.
2) Miksi syntyy P2 --> E?
3) Syntyykö myös P --> E2?
Jotta lopputulos olisi oikein, niin latauksen jälkeen kaikkien ladattujen nodejen handlet pitäisi muuttaa/poistaa, jotta ne eivät sotkisi uudelleenlatausta.
4) Eikös näistä handleista sanottu jossain että niitä käytetään vain aineiston sisään tuonnissa? Jos sen jälkeen ei tarvita, (vaan niistä näkyy olevan vain haittaa), eikä ne siinä tapauksessa jouda hävittää tuonnin lopuksi?
-j
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Taapeli/stk-upload/issues/9?email_source=notifications&email_token=AMQQPZALU2RW5HS7TJLWUDTP64LTTA5CNFSM4H5FMMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWNSUA#issuecomment-510450000, or mute the thread https://github.com/notifications/unsubscribe-auth/AMQQPZFWDUGPQDKYZCSTDWTP64LTTANCNFSM4H5FMMOQ.
-- -juha
-- -juha
Heh, se liitekuva ei näköjään tullut tänne saakka... Kokeillaan tätä tapaa (raahataan tähän tilaan)
Ja vielä: keltaiset pallot on Note. Ja niiden käsittelyssä on vielä jotain omaa jännää?
Hmmm. Poistin Tuon isomman ryhmän, ja kliksuttelin noita irrallisiakin vihreitä palloja kun ihmettelin mitä sellaiset avioliitot on, joihin ei liity henkilöitä. Kuva täydentyi:
Siirtelin ne marriaget toistensa viereen, joilla on sama id.
Minusta näyttää siltä että ratkaisu olisi juuri tuo Jorman mainitsema "latauksen jälkeen poistetaan kaikkien ladattujen noodien handlet". Silloin jokainen tarjokasaineisto/tuontierä olisi tosiaan täysin erillinen, ei olisi yhteisiä noodeja. Tätä olisi paljon helpompi käsitellä ja ajatella - ja vaikuttaa siltä että niin se oli alunperin ajateltukin? Onko mitään syytä miksi näin ei voitaisi tehdä? Mieleen tulee se että esim. paikat voitaisiin haluta pitää yhteisinä (referenssipaikat). Samoin on puhuttu referenssilähteistä. Ehkä niiden käsittely voidaan miettiä myöhemmin?
Tein myös pikaisen kokeilun, jossa Neo4j-latauksen loppuun panin suoraviivaisen handle-attribuuttien poiston:
match (b:Batch {id:$batch_id}) -[*]-> (a) remove a.handle
Näyttäisi toimivan ainakin minimaalisella kokeiluaineistolla.
[Nyt vasta luin ylläolevat kommentit!] Perusajatus oli aluksi se, että Batch-nodeen liitetään olennaiset "perussolmut" (Person, Family) ja nämä olisivat omistajan (User) yksin käyttämiä. Name, Note, jne löytyisivät perussolmujen kautta. Handlet toimisivat niin että uudelleenlatauksessa solmuja päivitettäisiin – mutta ajatuksestahan luovuttiin. (Juttu ei tullut valmiiksi, ainakin Name-noodeja luodaan koko ajan lisää eikä uudelleenkäytetä.)
Nyt kun esim. perheeseen tai toisiin henkilöihin viitataan handlen avulla, pitäisi laittaa lisäehto, että se kuuluu samaan Batch-erään. Jos handlet poistetaan ajon jälkeen jää jäljelle mahdollisuus, että kaksi käyttäjää lataa yhtäaikaa Sibelius-kopioitaan. Toisaalta handleen voidaan liittää perään Batchin id tai uniq_id, jolloin tuota ristiriitaa ei synny. – Ehkäpä jälkeenpäin ketään ei kiinnosta, että henkilöt E ja E1 ovat peräisin samasta Gramps-henkilöstä.
Yhtaikaiset lataukset ovat kai joka tapauksessa ongelma? Voisi hoitaa pakottamalla lataukset peräkkäisiksi, esim. käyttämällä tietokantalukkoa?
Samanaikaiset lataukset tosiaankaan ei ole ongelma, koska koko aineiston kantaan kirjoitus tapahtuu saman transaktion sisällä.
Tuli mieleen, että handlea ei tarvitsisi kirjoittaa lainkaan kantaan, jos niitä ei aiota säilyttää. Kerätään sen sijaan dictionary item[handle] = uniq_id
?
Tuo "handle -> id" -dictionary voi olla hyvä idea. Siitä voisi olla hyötyä myös esim. referenssipaikkojen käsittelyssä - kun XML-aineistoa sisään luettaessa kohdataan paikka, joka on jo kannassa oleva referenssipaikka, niin pannaankin tuohon dictionaryyn sen olemassa olevan paikan id, eikä luoda uutta paikkaa tarjokasaineistoon! Tässäkin voi siis soveltaa ohjelmistokehityksen periaatetta "We can solve any problem by introducing an extra level of indirection" (https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering)!
Korjattu commitissa c1e2037c ja c12f8effb23c0584cbaa8cf9bddc9fcf5c623574
Pitäisi olla mahdollista poistaa tarjokasaineistoeriä valikoidusti palvelimelta.