Warden

Je potřeba, aby klientská knihovna předávala seznam ostatních klientů jako hash, nikoliv jako pole. Používá to warden watchdog.

Konzultoval jsem s Kubou kvůli warden watchdog, řekl mi ale, že si již sahá přímo do databáze.

Přesto jsem kód upravil (revize b90ae7d4). Nově tedy nevrací pole polí klientů, ale pole hashí klientů. Názvy klíčů jsem převzal z formátu, v jakém přicházejí v SOAP objektu od serveru:

    ...
    my %client;

    $client{'client_id'}                = $response_data->{'CLIENT_ID'} ;
    $client{'hostname'}                 = $response_data->{'HOSTNAME'};
    $client{'registered'}               = $response_data->{'REGISTERED'};
    $client{'requestor'}                = $response_data->{'REQUESTOR'};
    $client{'service'}                  = defined $response_data->{'SERVICE'} ? $response_data->{'SERVICE'} : "-";
    $client{'client_type'}              = $response_data->{'CLIENT_TYPE'};
    $client{'type'}                     = defined $response_data->{'TYPE'} ? $response_data->{'TYPE'} : "-";
    $client{'receive_own_events'}       = defined $response_data->{'RECEIVE_OWN_EVENTS'} ? $response_data->{'RECEIVE_OWN_EVENTS'} : "-";
    $client{'description_tags'}         = defined $response_data->{'DESCRIPTION_TAGS'} ? $response_data->{'DESCRIPTION_TAGS'} : "-";
    $client{'ip_net_client'}            = $response_data->{'IP_NET_CLIENT'};
    ...

Super. S Kubou jsme se dohodli, že má větší smysl přímo db, ale tohle rozhraní je i pro analytiky, aby mohli získat mimo jiné description tags.

Jaký má význam to měnění undefů na "-"?

Pavel Kácha wrote:

ale tohle rozhraní je i pro analytiky, aby mohli získat mimo jiné description tags.

Ok, jasně.

Jaký má význam to měnění undefů na "-"?

Toto tam je z důvodu formátování výstupu. Tedy aby se odlišily ve výpisu potenciální hodnoty undef a "" (prázdný řetězec), které by jinak na výstupu vypadaly shodně (nic by se nevypsalo). To je jediná motivace, hlubší důvod v tom není.

To by si měl ale poladit (a undefy odchytat) klient/čtenář, ne? Co když to bude chtít vypisovat do html a dát si tam &nbsp nebo obrázek s křížkem? Knihovní rozhraní by se nemělo snažit data zkrášlovat.

Pavel Kácha wrote:

To by si měl ale poladit (a undefy odchytat) klient/čtenář, ne? Co když to bude chtít vypisovat do html a dát si tam &nbsp nebo obrázek s křížkem? Knihovní rozhraní by se nemělo snažit data zkrášlovat.

Tak ještě jsem nad tím dumal a po konzultaci s Tomem je to trochu složitější.

getClients(), která komunikuje se serverem a obdrží informace o dalších klientech záměrně u vybraných položek mění undef na "-", aby se odlišily případy, v nichž je undef (resp. databázový NULL) korektní hodnota. To se týká atributů service, type, receive_own_events a description_tags. U ostatních atributů by se undef objevovat neměl, tudíž tam se nemění.

V example-info.txt.pl (ukázkový klient vypisující info o ostatních zapojených klientech) bylo použito přeformátování undef na "unknown". Ve výsledném výpisu tak bylo rozlišitelné, co je korektní undef či NULL (zobrazený jako "-") a co chyba (zobrazená jako "unknown").

Dává to smysl z pohledu administrátora serveru, kterého tyto informace zajímají. Skript jsem převzal od Toma ze serveru a jen drobně upravoval, takže tento relikt mi tam zůstal. Navíc máme na serveru poměrně důsledné kontroly vstupů, takže asi jediný reálný scénář, kdy hrozí takto nekonzistentní hodnoty v databázi, může způsobit někdo z nás, kdo bude "ručně" manipulovat s databází.

V případě analytiků (Bodík, Honza V., ...) si myslím není potřeba takové detailní dělení. Bavil jsem se o tom s Honzou a shodli jsme se, že bude úplně stačit, pokud bude klient vracet undef bez dalších úprav; bez toho, zda jde o atribut, kde je undef korektní možná hodnota, nebo ne. Přeci jen i analytici mají do struktury Wardenu slušný vhled a budou schopni se vypořádat s případným undefem na místě, kde by být neměl.

• v revizi 688e5ba3
• v getClients() (WardenClientCommon.pm) jsem zrušil test, zda je proměnná definovaná. Fce tak vrací všechny hodnoty tak, jak je dostala od serveru.
• v example-info.pl.txt jsem upravil výpis tak, že všechny undefy se vypisují jako NULL (výstup tohoto klienta se tak tváří podobně jako výpis z tabulky v databázi)

S tímto bych to asi uzavřel, pokud k tomu ještě něco nemáš.

Za jakých okolností mohla v původním kódu vzniknout ta chyba, která se zobrazovala jako unknown?

Pavel Kácha wrote:

Za jakých okolností mohla v původním kódu vzniknout ta chyba, která se zobrazovala jako unknown?

Mohla vzniknout hlavně lidskou chybou při ručním zadávání vstupů do databáze (správce serveru by zadal NULL/undef někam, kam by neměl).

Čistě teoreticky mohla chyba vzniknout, i pokud by byla zadána špatná hodnota skrze administrační rozhraní a současně nebyla odchycena kontrolou vstupů. Tu má ale Tom celkem důslednou, takže tato varianta je spíše teoretická.