Kolekce a json zaznam pro harvesty

[kvasnicaj]

#datum
#název
#anotace
semínka...

[JanMeritus]

a
#pocetseminek
#timestamp

[Fasand]

@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]

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

[mariehaskovcova]

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

[JanMeritus]

@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]

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.

• Timestamp zmrazeni se zatim neuchovava, pridam tedy field. Pokud ale sklizen neni ve stavu "Running", seminka nejsou zmrazena, tedy vystup bude None.
• md5checksum seminek oddelenymi \n nebo neco k tomu?
• Typ sklizne neni jednoznacne urcen, ve sklizni mohou byt ArchiveIt, testovaci i seminka z kolekce. Mel by to byt dalsi field na modelu nebo se nejak "vypocita" z nastaveni sklizne?
• PlanovanyStart, Duration, Budget, DataLimit, DocumentLimit: tohle vsechno by mela byt nová fields na modelu? Vsechna pozitivni a s moznosti vyplnit jako prázdné? DataLimit ulozen jako float v GB a v jsonu vynasobeno 10^9?

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

• IDsklizne: primary key (e.g. 24) nebo nazev sklizne? Ted tam je jako jedine meta nazev sklizne, ten by mel zustat nebo neni potreba?
• datum: predpokladam datum sklizne, tedy "Naplánováno na" ve formatu "01.01.2021", "01/01/2021" nebo jine datum/format?
• Obecně maličkost: e.g. # Název sklizně nebo #Název sklizně, tedy mezera nebo ne?

[JanMeritus]

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

• myslim ze timestamp zmrazeni je dulezity procesni udaj, od toho momentu je to za kuratorov uzavrete, do budoucna s tym muzu byt aj nejake dalsi WF, ale to je na @mariehaskovcova. Per praxe to momentalne nastava prenastavenim stavu sklizne, idealne by bolo aby to mohlo byt zalozeno a naplanovano na nejaky datum, nasledne podrobne naplanovano kuratormi, pak to povereny kurator freezne a pre nas je to priznak, pripadne do budoucna taky notifikace, ze zde je hotovo, rsp je to priznak od kdy su seminka pro planovanu sklizen hotova - podla toho muze jet dalsi wf, prenastaveni datumu, refreeze pri uprave apod pripadne. Toto asi skor do buducna, kazdopadne potrebujeme nekde mit od kdy ty seminka su definitivne uzavrena a muzeme je prebrat na BE. Ted sice mame nastroj, ale jinak si volame co kdy je hotovo.
• md5 bud, anebo mozno jeste lepe jako json list typu seminko: md5 . Pro prvotni zavedeni ale asi staci jenom celkove md5 generovanyho data souboru
• typ sklizne, tu sa priznam, ze presne nevim jak je to ted nastaveno, vsechno se to ted micha dohromady, mozno by bolo zaujimavy znova u kazdeho seminka vest priznak typu sklizne aby se ty seznamy nemuseli pak tahat ty listy po jednom pro presne zachyceni jejich zdroju, ale naraz a rozdelit jenom v priznacich/strukture tj seeds: serials:M1 (list): seminko: md5, seminko: md5, ..., serials: ArchiveIT (list): seminko: md5, seminko: md5, ... ,...
  • prakticky se to totiz na BE taky vede tak, ze vsechny z rady serials, jdou na sklizen do hromady ale v ramci uloziska ty seminka vstupujici na sklizen mame jednotlive za jednotlive prispivajici sekce. Pokud by byl ale k tomu takyto handy soubor, nemusime to pak nijak inak resit
  • topics
    • bud separatne: hlavne podle stanoveneho data sklizne - napr volby, nebo nejakych specialnich prani (typu zachranna sklizen jenom jedneho webu),
    • pokud je datum jedno a typ je genericky tj topics a nejaka genericka kolekce - tj ne volby napr. tak jedou taky vsechny spolu v ramci jedny sklizne
• ad pole, jj, az na to, ze:
  • povinne, vzdy musi mit hodnotu: PlanovanyStart - kdy ma sklizen zacit, zatim staci jenom YYYY-MM-DD, ale pak idealne do budoucna i s casem, teda nejlip uz ted to davat jako timestamp. Bude slouzit k schedulingu na BE
  • nepovinne: Duration, Budget, DocumentLimit, DataLimit - souhlas

Data

• ID sklizne - nakonec ano, ale pridat jeste (doplneno vys):
• Lidsky citelny nazov sklizne
• Datum ano
• odsazeni klidne # Neco

[Fasand]

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]

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:

• hlavicka s hlavnima datama sklizne
• oddil collections, data pro jednotlive kolekce / elementy sklizne
• to ze seminka v collections muzu byt duplicitne
  • v ramci jedne collections zapovezeno
  • v ramci vicero collections ktere su v jedny sklizni to nevadi, aj tak si to sortime na unique nasledne

EDIT po meetingu 20201217:

• u serials je to dany
• obecne, sklizen je jen formulovatelna vzdy len pro dany type (typy jsou nekombinovatelne, eg. serials + topics)
• sklizen
  • vzdy volba pri rucnom nastaveni, na zaklade toho moznost kombinovat kolekce
    • type
    • combined
• technicka metadata (duration, budget, dataLimit, documentLimit) zatim dle profilu typu sklizne, pripadne dodelat na to inputy a pole v data modelu
• u topics (konstituce tematickych sklizni)
  • pridat pole collectionAlias, aggregationWithSameType
  • nesystemove kolekce - mozne pridat do sklizne, muzu konstituovat sklizen i bez dalsich kolekci, vystupuji jako nesystemove kolekce (OneShots)
• jmena
  • v ramci tohto modelu technicke jmeno sklizne, nova politika, pro vsechny sklizne se konstitutje se stylem Type_collectionAlias_YYYY-MM-DD
  • jde o tech jmeno z ktereho se konstruuje jmeno sklizne Type_collectionAlias-collectionAliasX_YYYY-MM-DD
  • kuratorske jmeno se prenasi jako jmeno kolekce v poli nameCurator
• hashe skusit dogenerovat dle seminek ala prazdny subor, newlines, md5
• zacit vyuzivat frekvencnost pre pre-planning, zaclenit do procesov s freeze - viz ale nove issue scheduler Scheduling sklizni s u kolekci s pravidelnou frekvenci #568

{
  "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]

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]

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]

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

[mariehaskovcova]

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

[Fasand]

@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 "Serials_Custom_..." 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]

@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 "Serials_Custom_..." 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]

Čí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 Uprava Sklizni #468 (comment) "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]

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

3. 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 dle aggregationWithSameType), 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.

4. 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

5. 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]

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]

• probehl meeting, kratka poznamka, doplnil @Fasand
• Objekt sklizne obsahuje dalsi parametre:
  • harvest_type: serials | topics | tests | totals
  • paraharvest: boolean
  • automatic (podminuje tech. data)
  • manuals: podminuje nepritomnost tech. dat, pokud je nezaskrtnuto (default), znamena automatic (@JanMeritus muze byt?)
• na objekt sklizne se budou moci vazat jenom interni kolekce (z puvodnich kolekci se migraci provedou 1:1 interni a externi)
• existuje neco ako interni kolekce - nerovna se typu sklizne TESTS
• nameCurator je oficialni nazev kolekce od kuratoru (plati je pro interni kolekce, dalsi typy nemaji nazev ani ID)
• konverzni tabulku k 2
  • dodat skript ktery vytaha basic info k sklizni (zejmena meno) pres manage.py
    • id, nazev, je tam topic collection?, je tam serials frekvence?, je tam topic frekvence?, zaškrtnuté archiveit/test?
    • vypsat v naformatovane tabulce nebo idealne dat parametr absolutni PATH output CSV souboru a vypsat do toho
  • @habetpet nasledne vytahne na produkci a doda zpatky soubor v pozadovanem tvaru

[JanMeritus]

• manuals: podminuje nepritomnost tech. dat, pokud je nezaskrtnuto (default), znamena automatic (@JanMeritus muze byt?)
  • ano, ale ako datatyp je vzdy vyzadovan bud automatic a manuals
• muzme @Fasand potvrdit zadani?

[Fasand]

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]

@habetpet prosim o test

[mariehaskovcova]

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