search

WebarchivCZ / Seeder

Seeder - Czech webarchive curating tool and public site
MIT License
15 stars 2 forks source link

Kolekce a json zaznam pro harvesty #402

Open kvasnicaj opened 7 years ago

kvasnicaj commented 7 years ago

datum

název

anotace

semínka...

JanMeritus commented 6 years ago

a

pocetseminek

timestamp

Fasand commented 4 years ago

@JanMeritus @horakjirinkp Chcete k tem seminkam do sklizne pridat jeste neco z tohoto? Zatim jsme se domluvili na tom nazvu sklizne, ktery je na testu, tak pomuzou vam i ty dalsi vlastnosti nebo s tim mam pockat?

Fasand commented 4 years ago

Prosim o oziveni tematu nebo uzavreni/posunuti do pozdejsiho milestonu.

mariehaskovcova commented 4 years ago

poprosím o vyjádření @JanMeritus a zatím posouvám do pozdějšího milestonu

JanMeritus commented 3 years ago

@Fasand 

#IDsklizne
#datumGenerovani (timestamp)
#PocetSeminek
#TimestampZmrazeni (seminek)
#md5checksum
#NázevSklizne
#AnotaceSklizne
#TypSklizne (topics, serials, targeted, continuous, prip. do budoucnaprofil)
#PlanovanyStart (timestamp)
#Duration (s) - integer
#Budget -integer
#DataLimit (bytes) - pre kuratorov ale v seedru v ramci nastaveni mit jako GBs
#DocumentLimit  - integer

ps ako nad tym rozmyslam, mozno by toto mal byt seperatny file typu json, stiahnutelny ala IDsklizne/metadata a v samotnom fily seminek by bolo len

# IDsklizne(unikatni identifikator)
# Nazev(lidsky citelny)
# Anotace (docasne, bez stylistickych znaku, newlines etc)
# datumGenerovani (timestamp)
# pocetseminek
Fasand commented 3 years ago

Souhlas, v tomto mnozstvi bude samostatny json davat vetsi smysl a nemusi se potom drzet striktniho poradi informaci. Kazdopadne mam k tomu nekolik otazek/pripominek.

Co se tyce toho aktualniho filu seminek /seeder/harvests/<id>/urls:

JanMeritus commented 3 years ago

Vys som trochu updatoval, pole ID sklizne by melo zabezpecit moznost parovat obidva vystupy (pracovne im rikam data soubor a metadata soubor) ak bude nutnost. Do budoucna by ale asi bylo optimalni pak vest jenom ten metadata (viz napad s listem), viz niz, pak si ho na BE budeme dal spracovavat. Na ty metadata by sa mel zavest novy tiket, asi to nebude hned:

Metadata

Data

Fasand commented 3 years ago

Diky za objasneni. Trochu mi z toho popisu rozdeleni seminek do typu sklizne vyplyva spis jeden velky JSON nez dva soubory. Je nejaky duvod proc to tak neudelat nebo by to davalo smysl?

Neco jako:

{
  "idSklizne": 23,
  "datumGenerovani": 1608106203712,
  ...
  "seeds": {
    "serials:M1": [
      "https://google.com": "41a583949459006c49ea6102854cb72e",
      ...
    ],
    "topics": [
      {
        "id": 11,
        "nazev": "První světová válka",
        "seeds": [ ... ]
      }
    ]
  },
  ...
}

Pokud jsem totiz spravne pochopil ty md5 sums, ze bys je chtel pro kazde seminko, tak by se vsechna seminka musela objevit jak v metadata tak v data. I kdyz uplne nerozumim, k cemu by tam ty md5 vlastne byly u kazdeho seminka misto treba jedne md5sum pro vsechna seminka uz v tom formatu rozdelenem na typ sklizne (i kdyz muselo by to byt vzdy nejak serazene) nebo jeste neceho jineho. Jestli se vam to ale hodi per-seminko, tak to samozrejme neni problem.

Jediny problem, co me napada s tim rozdelenim (coz ale mozna neni problem) je, ze se teoreticky muze objevit jedno seminko ve vice typech sklizne, coz se ted resi pres sety v Pythonu. Napr. zdroj muze mit nastavenou frekvenci 2x rocne, byt relativne nove a mit technickou kontrolu, tedy zobrazilo by se v "serials:M2", "serials:ArchiveIT" a "tests". Nebo dva zdroje muzou mit teoreticky stejne seminko a stane se to same.

Ten datumGenerovani myslis timestamp kdy byl dany soubor načten, tedy bude jiny pri kazdem nacteni souboru, nebo neco jineho? V tomto pripade by treba md5sum celeho datoveho souboru nedavala smysl, protoze by pri kazdem nacteni byla trochu jina. Datum sklizne ("Naplánovano na") jsi dal pryc naschval nebo to ma byt ten datumGenerovani?

Na datum bych jinak asi pouzil ISO 8601 format, tedy treba pro aktualni timestamp timezone.now().isoformat() -> 2020-12-16T08:28:24.551650+00:00.

JanMeritus commented 3 years ago

urcite, json je supr, myslim ze asi muzeme jet rovnou do neho, ty data som chtel dokym si nepripravyme parser a nejaky solidnejsi scheduler na BE. Nicmene jak nad tim uvazujem muzeme zacat uz rovno s timto. Celkovo aj vzhladom standardizacii dopytov pre vsechny sklizne - aby se do iste moznosti chovali vsechny systemovo rovnako, co se tyce nazvoslovi, navrhujem json ala viz niz. Myslim si ze ide o systemove riesenie.

S tim ze pole collectionAlias a aggregationWithSameType vyplnuje tech. operator pro jednotlive kolekce, rsp duration, budget a dataLimit pre jednotlive sklizne. Napr. Doc Limit 0 znamena ze limit na documenty nie je

Struktura je nasledovna:

EDIT po meetingu 20201217:

{
  "idHarvest": 23,
  "dateGenerated": 1608106203712,
  "dateFreezed": 1608106203712,
  "plannedStart": 2020-12-16T08:28:24.551650+00:00,
  "type": "serials",
  "combined": true,
  "name": "Serials_YYYY-MM-DD_M1-ArchiveIt"
  "anotation": "Anotace 1  + " ~ "+ Anotace X",
  "hash": hashSeminekCombined (md5),
  "seedsNo": 300,
  "duration": 259200,
  "budget": 10000,
  "dataLimit": 10000000000,
  "documentLimit": 0,
  "collections": {
       { "name": "Serials_M1_YYYY-MM-DD", "collectionAlias": "M1", "anotation": "Serialova sklizen s mesicni periodicitou.", 
          nameCurator: "null", "idCollection": 2, "hash": hashSeminekCombined, "seedsNo": 240, "aggregationWithSameType": true,
         "seeds":  ["https://google.com","https://yahoo.com",...] },
       { "name": "Serials_ArchiveIT_YYYY-MM-DD", "collectionAlias": "ArchiveIT",  "anotation": "Vyber seminek k archivaci.", 
          nameCurator: "null", "idCollection": 3, "hash": hashSeminekCombined, "seedsNo": 60, "aggregationWithSameType": true,
         "seeds":  [ "https://facebook.com","https://yahoo.com",...] }
      }
  }
}

{
  "idHarvest": 24,
  "dateGenerated": 1608106203712,
  "dateFreezed": 1608106203712,
  "plannedStart": 2020-12-16T08:28:24.551650+00:00,
  "type": "topics",
  "combined": true,
  "name": "Topics_YYYY-MM-DD_WW1-JAKom"
  "anotation": "Anotation 1  + " ~ "+ Anotation X",
  "hash": hashSeminekCombined,
  "seedsNo": 90,
  ...
  "collections": {
       { "name": "Topics_WW1_YYYY-MM-DD", "collectionAlias": "WW1", "anotation": "Sklizen k xtemu vyroci Velke valky ....", 
         "nameCurator": "První světová válka", "idCollection": 11, "hash": hashSeminekCombined,  "seedsNo": 70, "aggregationWithSameType": true,
         "seeds":  ["https://google.com","https://yahoo.com",...] },
       { "name": "Topics_JAKom_YYYY-MM-DD", "collectionAlias": "JAKom", "anotation": "Sklizen k vyroci J. A. Komenskeho k vyroci 400 let.", 
         "nameCurator": "Jan Amos Komensky 400 let",  "idCollection": 13, "hash": hashSeminekCombined, "seedsNo": 20, "aggregationWithSameType": true,
         "seeds":  ["https://google.com","https://yahoo.com",...] },
  }
}

{
  "idHarvest": 25,
  "dateGenerated": 1608106203712,
  "dateFreezed": 1608106203712,
  "plannedStart": 2020-12-16T08:28:24.551650+00:00,
  "type": "topics",
  "combined": false,
  "name": "Topics_YYYY-MM-DD-KrajVolby202rI"
  "anotation": "Anotation",
  "hash": hashSeminekCombined,
  "seedsNo": 340,
  ...
  "collections": {
       { "name": "Topics_KrajVolby202rI_YYYY-MM-DD", "collectionAlias": "KrajVolby202rI", "anotation": "Sklizen ku krajskym volbam. Beh1.", 
         "nameCurator": "Krajské volby ČR 2020", "idCollection": 143, "hash": hashSeminekCombined,  "aggregationWithSameType": false, "seedsNo": 340,
         "seeds":  ["https://google.com","https://yahoo.com",...] }
  }
}
Fasand commented 3 years ago

Super, takhle mi to dava docela smysl. Jenom teda nevim jak vyresit ty collections s tim, jak to je doposud resene

Aktualne je ve sklizni pouze vyber veci, ktere by se tam mely objevit, ale na zadne kolekce to realne neni rozdelene. Tedy ani nemuzou byt parametry jako aggregationWithSameType pro ruzne kolekce, jedine pro vsechny zaroven, tedy vlastne pro celou sklizen. Pokud bychom chteli nejake takove kolekce vytvorit, tak by to samozrejme bylo realne, ale byl by to dost velky zasah do implementace.

Nechces si ohledne toho spis nekdy zavolat a probrat to poradne, pripadne s kymkoliv dalsim, kdo s tim bude pracovat? Uz si myslim docela rozumime, jak by to melo cca vypadat, ale porad vlastne nevim, jak bych to v aktualnim stavu bez velkych zmen udelal.

JanMeritus commented 3 years ago

ahoj, urcite ano, napr s @mariehaskovcova by to bolo idealni si dat online call, jestli je to tymto smerem ok. Ten model co tu mam je zalozen na tom, ze v podstate cokoli je z jeho hladiska kolekce seminek a sklizen muze byt bud z jedny nebo vicero kolekci v technickem slovazmyslu (jednorazove seminka tvori jednorazovou kolekci sklizne, ktora se ale muze napr. reiterovat - napr volby). Zavolat si muzme cim driv tim lip. Nasledne pozadavky co visi (napr na api a pod.) by pak sli dle tohto zakladniho modelu.

JanMeritus commented 3 years ago

@Fasand @mariehaskovcova az budete mit cas, prosim dajme call, at vime s cim pocitat pro automatizaci (FYI @habetpet )

mariehaskovcova commented 3 years ago

předběžně počítáme s callem v květnu, datum upřesníme

JanMeritus commented 3 years ago

@habetpet prosim nastudovat

Fasand commented 3 years ago

@JanMeritus Zacal jsem na tom delat a potreboval bych objasnit par veci nez tam nahazu migrace. Prosim bud odpovedet nebo potvrdit/opravit kdyz popisuji jak to ted sam chapu.

  1. Custom seeds: kazda sklizen muze mit mimosystemova seminka a extra zdroje. Mela by se tato seminka spojená dostat do "SerialsCustom..." nebo napr custom semínka a custom zdroje by mely byt oddelene? Platí opět aggregationWithSameType=True?
  2. Harvest type: sklizne dostanou nove pole type, ktere muze mit hodnotu "serials" nebo "topics", nic jineho. V jakem bode by mela probihat kontrola, ze v "serials" sklizni nejsou zadne topics a naopak – asi pri zadani do formulare? Respektive je vylozene spatne, kdyz to bude namichane nebo to je na kuratorech, aby ty sklizne nemichaly?
    • Musim nastavit default, tedy asi "serials", a jelikoz stare sklizne nemely zadnou takovouto kontrolu, nemuzu ji ted pridat na uroven modelu, jedine do toho EditView a pri ziskavani JSONu spatne konfigurovane sklizne i tak vypsat nebo hodit chybu
  3. combined: nove pole na Harvest, default=True? Znamena neco v ramci jak se JSON generuje nebo se ma do nej jen propsat a nic neovlivnuje?
  4. Extra fields duration, budget, dataLimit, documentLimit: přidat všechny jako PositiveIntegerField(null=True,blank=True) nebo zatím jen vždy posílat to co jsi psal v tom JSON příkladu? Kdyz chci nacist JSON sklizne ktera nema ta fields nastavena, vratim proste None nebo ty předdefinované hodnoty? Případně místo null=True dát default=ty z příkladu?
  5. Datumy: pridat fields date_frozen a planned_start, obe musi byt null=True, blank=True. Vypsat do JSONu v isoformatu nebo jako timestamp bez timezonu? Iso mi prijde lepsi, ale v prikladu jsou obe moznosti.
  6. dateGenerated: proste timezone.now().isoformat(), tedy cas nacteni JSONu?
  7. idCollection a nameCurator == None, aggregationWithSameType=True pro vsechny serials kolekce (vcetne Tests, OneShot, ArchiveIt) nebo nejake vyjimky?

Sorry jestli je to takhle moc otazek i po tech dvou callech, jenom bych tam fakt nerad vytvoril migrace na X novych poli na Harvestu a za tyden zjistil, ze tam vubec byt nemusi nebo ze maji vypadat uplne jinak.

JanMeritus commented 3 years ago

@Fasand ahoj, pisu rovnou do textu:

zakladni pojmy: kolekce, sklizen

  1. Custom seeds: kazda sklizen muze mit mimosystemova seminka a extra zdroje. Mela by se tato seminka spojená dostat do kolekce "SerialsCustom..." nebo napr custom semínka a custom zdroje by mely byt oddelene? Platí opět aggregationWithSameType=True?
    1. u mimosystemovych nebo i systemovych seminek, ktere se pridavaji do sklizne extra, jde o specialni kolekci tzv OneShot, ta je by definition agregovatelna a nese vzdy type matersky sklizne, Eg Serials, Topics, Tests . Mela by se pak v nejaky forme ulozit k dany sklizni, ale pro novu sklizen je jakoby vzdy prazdna.
  2. Harvest type: sklizne dostanou nove pole type, ktere muze mit hodnotu "serials" nebo "topics", - taky "tests", "totals", "paraharvests" pripadne jine oznaceni (pokud pribudne novy typ sklizne) V jakem bode by mela probihat kontrola, ze v "serials"
    1. sklizni nejsou zadne topics kolekce a naopak – asi pri zadani do formulare? Ano
    2. Respektive je vylozene spatne, kdyz to bude namichane nebo to je na kuratorech, aby ty sklizne nemichaly? Nemelo by dochazet k michani, typologie serials sklizni je zalozena na frekvenci, u Topics vicemene na obsahu
  3. Musim nastavit default, tedy asi "serials", a jelikoz stare sklizne nemely zadnou takovouto kontrolu, nemuzu ji ted pridat na uroven modelu, jedine do toho EditView a pri ziskavani JSONu spatne konfigurovane sklizne i tak vypsat nebo hodit chybu combined: nove pole na Harvest, default=True? Znamena neco v ramci jak se JSON generuje nebo se ma do nej jen propsat a nic neovlivnuje? i. o kolik starych sklizni jde ? nemyslim ze je to velke mnozstvi (cca do 200) zde by mozna bylo mozne udelat rucnou definici pro migraci, zmeni to pak dotaz c 3 ?
  4. Extra fields duration, budget, dataLimit, documentLimit: přidat všechny jako PositiveIntegerField(null=True,blank=True) nebo zatím jen vždy posílat to co jsi psal v tom JSON příkladu? Kdyz chci nacist JSON sklizne ktera nema ta fields nastavena, vratim proste None nebo ty předdefinované hodnoty? Případně místo null=True dát default=ty z příkladu?
    1. zde by melo mozny byt v zakladu nakonfigurovat hodnoty pro jednotlive typy sklizni
    2. rozvoj do buducna pocital s tim ze by je mel pro jednotlive harvesty predvolene hodnoty. Pro rozvoje se pocitalo s tim ze by je pak mohl menit zatim jenom technicky operator (a pripadne pak i kurator)
  5. Datumy: pridat fields date_frozen a planned_start, obe musi byt null=True, blank=True. Vypsat do JSONu v isoformatu nebo jako timestamp bez timezonu? Iso mi prijde lepsi, ale v prikladu jsou obe moznosti. ISO bude lepsi
  6. dateGenerated: proste timezone.now().isoformat(), tedy cas nacteni JSONu? ano
  7. idCollection a nameCurator == None, aggregationWithSameType=True pro vsechny serials kolekce (vcetne Tests, OneShot, ArchiveIt) nebo nejake vyjimky?
    1. "Tests" je rezervovany nazev pro typ kolekce
    2. "NameCurator" je nazev kolekce od kuratoru

Kdyby neco su na telefonu pripadne zitra online ak budes mit aktualizovany json, nebo nejake dotazy.

Fasand commented 3 years ago

Číslovaná reakce na předchozí komentář:

  1. RE OneShot: ahh, tak to jsme jenom pracovali s různými definicemi, já jsem vycházel z https://github.com/WebarchivCZ/Seeder/issues/468#issuecomment-490888678 "zdroje, které se archivují jen jednou. V seederu je to jako frekvence jednorázově", tedy zdroje, které mají nastavenou frekvenci 0 (Once only). Po rychlém callu tedy do OneShot zahrnuji zdroje s frekvencí 0 + custom_seeds + custom_sources.

  2. Harvest type: OK, pridal bych na EditView kontrolu, ze pokud je vybrana frekvence tak nemuzou byt vybrane tematicke kolekce a naopak, stare sklizne to neovlivni. Jaká jsou omezení pro "test", "topics", "paraharvests"? Mohou byt custom seminka/zdroje, atp.?

    • O "paraharvests" slysim poprve, totals je ve zminenem issue popsany jako "celoplošná sklizeň - nedělá se přes Seeder"

  3. Default pro harvest type: Nevim presne kolik je sklizni na testu/produkci, ale zkratka by to ovlivnilo vsechny. Pokud by byly jasne podminky pro to, co znamenaji jednotlive typy sklizny, asi by sla napsat migrace, ktera by je spravne rozdelila, ale trochu zalezi jestli je to vubec nutne u starych sklizni, proto bych mozna dal proste default="serials".

    • Porad ale nevim, co vlastne to pole combined znamena.

  4. Extra fields: OK, vytvoril bych asi novy model HarvestConfiguration s fields: "harvest_type" (serials, topics, ...), "key" (Char), "value" (Char). V momente generovani JSONu by se vytahly vsechny key-value pairs pro dany typ sklizne a pridaly se do JSONu pro danou sklizen. Co tedy nebude v HarvestConfiguration, to se do JSONu neprida a naopak bude jednoduche menit/pridavat nastaveni. Tim padem by ale nastaveni bylo vzdy jen pro typ sklizně, ne pro konkrétní sklizeň. Pokud by byla potřeba mít custom nastavení pro každou sklizeň, musela by být (navíc) nová pole přímo na sklizni, tak nevím, trochu by se to tím zaplevelilo.

  5. idCollection a nameCurator: u tematickych kolekci jsou tato pole jasná, protoze to jsou samostatne objekty v databazi, ale Serials, Tests, ArchiveIt a OneShot jsou dynamicky načtené podle checkboxů na sklizni. Zadne ID ani nameCurator tedy nemaji. aggregationWithSameType tedy taky musi byt pevne nastavene pro kazdy typ kolekce, tedy např. "všechny Tests kolekce maji aggregationWithSameType=True" apod.

Další otázky:

  1. Pole plannedStart je nové pole nebo aktuální scheduled_on? Chápu je totiž stejně, jenomže scheduled_on je datum bez času a tvůj příklad byl celý isoformat

  2. Datumy v name u sklizně a kolekcí: jedná se o aktuální datum nebo o datum kdy to bylo vytvořeno/upraveno? Datum vytvoření bude konzistentní, i když některé tématické kolekce byly asi vytvořeny dávno a postupně upravovány – datum úpravy se zase změní při každé změně. No a zbytek datumů pro sklizeň už je v dateGenerated, dateFrozen a plannedStart, tak jenom nevím, který by tam teda měl být. Plus třeba u kolekcí typu serials/OneShot žádné datum vytvoření neexistuje, takže asi dnešní datum?

Kdyztak budu taky na telefonu i na Slacku a mezitim dodelam ty jasne zmeny.

JanMeritus commented 3 years ago

ahoj @Fasand , po dlhsi odmlce znova pisi, FYI @habetpet @mariehaskovcova

  1. ok

  2. ok. omezeni pro topics rsp ine druhy by meli byt ze to muzu byt jenom kolekce daneho typu, eg. topics. Vyjimka - oneshots muzu byt v kazdem z druhu.

2.b paraharvests su sklizne sklizni, delaji se pro doplneni obsahu jinde jiz sklizeneho pomoci sklizeni, rucniho nebo strojovyho

  1. ako pokud je jich trochu, mozno neni nutne psat migraci ale mapovaci tabulku, udelal by se export pro vsechny historicku, dala by se kuratorum, ty by dopsali typy a podle toho by se to prevedlo v kazdem z jednotlivych pripadu, mozna to bude rychlejsi pokud jde o dve tri stovky tezko parametrizovatelne minulosti vynucujici si hlavorucni praci

3.b boolean pole combined znamena jestli v tom harvestu bylo mozne kombinovat vic kolekci nebo nikoliv. Melo by se nastavovat rucne. Je totiz mozne ze kuratory chteji vic kolekci, ktere pri jednotlivych kusech jsou kombinovatelny - eg vsechny topics naraz (maji totiz potenci dleaggregationWithSameType), pripadne chteji kazdou z kolekci sklizet samostatne a nekombinovat. Jde o rozhodnuti lidskeho operatora, samozrejme pri dodrzeni vsech podminek kombinovatelnosti definovanych vyse, ktere jinak nepusti.

  1. Urcite to stavet tak ze kazde id harvestu (jednotliva iterace) muze myt sve vlastni specificke hodnoty. V zakladu muzu byt stejny, ale je mozny ze z nejakych duvodu (napr skliditelnost, presnejsi zacileni, experiment) se budou pro jednotlive sklizne menit. Bolo by proto dobre vyresit ze typ sklizne ma sice defaultni hodnoty, ale jednotlive pripady muzou byt pozmeneny (a ano, deje se to obcas, vychazim z realneho uziti). Nekde to skladovat musime, pokud to narusuje model muzeme si na to udelat samostatnou bazi, ale predpokladam, ze by to bolo lepsi mit taky v seedru ako soucast zadani poptavane sklizne.

4.b neni mi jasny proc by tam v pripade ze tam nic nebude nemeli byt nulovy nebo nejaky indikativni hodnoty, aby dalsi spracovani nezhavarovalo, nebo sme nemuseli overovat cely set podminek pro kazde pole samostatne

  1. zde je to otazka, jak se tedy ukladaji aby byli historicky dostupne, pokude nemaji vlastni interni ID? 2. Jmeno Vicemene ok - je null, Jmeno kuratora ktery je zadal by melo byt aspon u OneShot a Test, ktery je zadal.

Extra

  1. Scheduled_on som tam nedaval, ale mentalne je to asi stejne pole, idealne by bolo pokud by slo o isoformat vc casu, nejenom dne
  2. Melo by jit o datum na kdy je sklizen naplanovana (tj plannedStart), ale z realneho uziti tam vzdy (zejmena u DD) davame datum aktualniho spusteni sklizne, ked se lisi. Zde dochazi obcas k rucni zmene, ale Seeder ak vychazime z premisi ze zachycuje zejmena objednavku by mel mit plannedStart, kdyz tak se to rucne nebo strojove upravi. Spetna mapovatelnost by mela byt zajistena vzdy ID harvestu
Fasand commented 3 years ago

Děkuji za objasnění @JanMeritus. Většina z toho je tedy relativně jasná, tak jen pár reakcí:

  1. Typy sklizní tedy: "serials" (podle frekvence), "topics" (tématické kolekce), "tests" (technická kontrola), "totals" (úplně všechno zaškrtnuté nebo jen bez kontroly pravidel?), "paraharvests" (prostě bez kontroly pravidel, aby se dalo zaškrtnout cokoliv nebo něco special? Vybrat sklizeň ve sklizni zatím není možné, takže si nejsem jistý, že to správně chápu); a kterákoliv sklizeň může mít i OneShot zaškrtnuté, ale není to samostatný typ sklizně

  2. RE Migrace: to by asi byla možnost, jenom by se to muselo nějak zkorigovat. Respektive dal bych tam tedy ze typ sklizne nesmi byt prazdny, default na "serials" a kdyz mi date tu mapovaci tabulku (Harvest ID : Harvest Type), tak by se to zpětně přenastavilo pomoci nejakeho manage.py scriptu. Psat to primo do migrace by asi byl vetsi problem nebo by tam minimalne taky musel byt nejaky default.

  3. RE Extra fields: v tom pripade bych na model sklizne dal nove fields: duration, budget, dataLimit, documentLimit, vsechny PositiveInteger(blank=True) s tim, ze by se pri vytvareni sklizne mohly a nemusely zadavat a jejich vysledna hodnota by se nastavila az Harvest.save() podle pravidel: a) Pokud kurátor nastavil custom hodnotu, ta zůstává b) Pokud je hodnota prázdná, zkusím pro daný typ sklizně načíst hodnotu z HarvestConfiguration a pouziju tu c) Pokud ta konfigurace chybí, použiju default a případně se dá později změnit. Ty defaults můžu použít z tvého příkladu nebo by měly být jiné? Těmi defaults by se snad vyřešilo co popisuješ v 4.b, tedy ve chvili kdy si generuji JSON uz tam nejake hodnoty nastavene musi byt a muzu s nimi tedy počítat.

  4. RE idCollection a nameCurator: aktualne se jen zmrazi vsechna seminka dohromady, tedy to neni vubec rozdelene na kolekce. V novem postupu by se pri spusteni sklizne do noveho pole zmrazil cely JSON, tedy by to jiz bylo rozdelene na kolekce serials apod, ale jelikoz ty budou generovane dynamicky, tak furt nebudou mit vlastni interni ID. a) nameCurator jsem chapal jako jmeno kolekce, ktere ji dal kurator, ne jmeno samotneho kuratora. V pripade tests bych mohl nacist set vsech Source.owner pro zdroje s technickou kontrolou, u OneShot potom jedine podobne kdyby byly zadane custom zdroje nebo s nulovou frekvenci, jinak s custom semínek nic nevyčtu, takze by to bylo prazdne.

JanMeritus commented 3 years ago
JanMeritus commented 3 years ago
Fasand commented 3 years ago

Je to na testu 👍 Mimo to bude pár dalších změn z hlediska zadávání sklizní na frontendu, viz další issues

JanMeritus commented 3 years ago

@habetpet prosim o test

mariehaskovcova commented 7 months ago

příležitostně prosím zhodnoť @dragounv, díky