Uprava logovani Statistics: Vroceni zobrazovanych materialu a separatni root dates

[JanMeritus]

Bolo by vhodne logovat vroceni del ciselnou hodnotu povoleneho typu YYYY misto stringu (predpokladam ze jde o pole datum_str ?). Momentalne se loguje siroke rozmezi nepovolenych hodnot typu string z rootPiD ktere neumoznuji dalsi strojove spracovani bez zloziteho filtrovani a taky a to obzvlast, realnou kontrolu licencniho plneni.

Granularita na rok je idealni pro kontrolu licencniho plneni. Princip: primarne identifikovat vyskyt 4cif cisla, zbytek zahodit, nebo pouzit uz nejaku pro to urcenou hodnotu. V SOLR scheme to musi mit kvuli hledani nejaky definitivni nebo aspon aproximovany rocnik (eg. polerok ?).

1. Prevest:

• u pripadu 6.2016 -> 2016
• stejne tak i pro miru nejistoty:
• u pripadu c2014 -> 2014
• u pripadu [2010?] -> 2010

2. U vic viskytu 4cif cisla v retazcu napr, pri carke - brat to nejvyssi odpovidajici formatu YYYY

• 2000, c1994 -> 2000
• 2006 [i.e. 2007] -> 2007

3. pokud 4 cif cislo neobsahuje, nastavi se domluvena defaultni hodnota, napr. 1000

4. periodika

   • zde viz i obecne rozsireni #798
   • zde je idealni co sebrat hodnotu nejblizsi pro vroceni dane stranky, svazku a rocniku. Je nutne mit tuto konkretni hodnotu pro zobrazovanou polozku, eg. stranku
   • pokud neexistuje je to problem, ale treba v tom pripade sebrat hodnotu nejvyssi (1989-2014) -> 2014
   • pro matersky titul, tj. rootPID a rozsah jeho vychazeni, se muze vyuzit samostatnych poli a hodnot jako datum_begin, datum_end

[zabak]

Předpokládám, že stačí vzít ze solru vhodné existující pole, které se používá pro fasetu rok vydání, jen prosím nezapomeňte že v K7 to bude jiné pole.

[honza-rychtar]

Předpokládám, že stačí vzít ze solru vhodné existující pole, které se používá pro fasetu rok vydání,

No právě že ne. Starý indexer převáděl jen roky v pro něj správném tvaru a u všeho ostatního dával 0. To je ten problém filtrování a řazení. Takže c2014 -> 0, [2014] -> 0, [2014?] -> 0 atd

jen prosím nezapomeňte že v K7 to bude jiné pole.

Ano. Nový indexer už všechny tyto konverze dělá a datum ukládá několikrát pro různé potřeby. Konkrétně pro rok v číselné podobě jsou dvě pole date_range_start.year a date_range_end.year

[JanMeritus]

@pavel-stastny prosim zahrnies to este do tej verzie co pripravujes? mozes oznacit issues co sa tam vojdu podla teba milestonom?

[pavel-stastny]

@JanMeritus Ok. Podivam se na to.

[pavel-stastny]

Přidán formater, který formátuje datum na roky. Bere vždy ten větší z nalezených.

@JanMeritus Podívej se prosím na tento test, jestli to pokrývá všechny formy zápisu. Případně, zda bys něco přidal.

Ohledně nenaparsování/nerozpoznání hodnoty: Osobně bych doporučil hodnotu v logu neuvádět vůbec a při následném zpracovávání logů by mohlo rozhodnout co s tím, případně jaký datum/rok doplnit.

[zabak]

Případy 191- a 19uu v tom testu by se měly vyhodnocovat jako 1919 a 1999, pokud hledáme nejvyšší možný rok.

[pavel-stastny]

ok. A ohraničené je to aktuálním rokem? Tedy pak případ 20-- jako 2021?

[zabak]

Jo, to dává smysl.

[JanMeritus]

@pavel-stastny za mne ok, prosim jenom, pokud se rok nenajde, kde, nebo jak se nastavuje defaultni hodnota? eg 0001 /1000 whatever

[pavel-stastny]

@JanMeritus Jak jsem již napsal v tom předchozím komentáři: V tomto případě bych nedával žádnou implicitní hodnotu, naopak bych nechal položku prázdnou (resp. by v logu vůbec nebyla) a logiku co se záznamem bych nechal až na úroveň zpracování logů... (logstash, skript, atd... )

[JanMeritus]

@pavel-stastny v zasade ok, muze to vznikat az pri parsovani logu pokud je pole NaN, ale v tom pripade treba mit jistotu ze nepritomnost hodnoty, tj vsechno co je NaN je skutecne nedostupnost data vyvolana jeho nepritomnosti po filtraci v Kram a ne jinymi provoznimi okolnostmi

[JanMeritus]

@pavel-stastny je v Kramerius verze 5.4.8-dnnt vyreseno taky 800 ? Neni v popisu

[pavel-stastny]

@JanMeritus jj... upravil jsem popis.

[JanMeritus]

diki 👍