SE - import XLS které má v poli URL něco jiného než URL zhavaruje #407
Assignees
Disassembler
Clear assignees
Disassembler
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Disassembler/Spotter-VM#407
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
ticket:
https://sahana.spotter.dasm.cz:8443/eden/admin/ticket/eden/__ffff_31.30.50.4.2020-04-11.22-15-06.a1db8285-2aac-413b-9d89-5e79267b7250
hláška končí:
ValueError: unknown url type: '.'Týkalo se u importu Organisations, ale předpokládám že to může být všude.
do buňky pro URL logo jsem totiž dal místo URL tečku.
chlapci by si měli udělat nějaký fix na importy nesmyslů, aby jim to nepadalo
changed milestone to %2
changed the description
ok, tak bude to asi ještě složitější, havaruje to i při vytvořené organzaci, která má pole, které bylo importované prázdné, ale patrně po pokusu uložit organizaci to zhavaruje, protože se mu nelíbí hodnota "none" Tj. vysvětluji si to tak, že jakmile se importne prázdné pole kde je mandatory pole, tak už uložení selže.
ticket: https://sahana.spotter.dasm.cz:8443/eden/admin/ticket/eden/__ffff_31.30.50.4.2020-04-11.22-34-59.d5f5b00d-84f7-4b97-b224-a99e323154e0
končí:
ValueError: invalid literal for int() with base 10: 'None'pozn.: Tento způsob importu, který odhaluje problémy, dělám proto, že moje importy budou mít mnoho položek a srát se s tím laděním je fakt otravné... Zároveň předpokládám, že i pokusy uživatelů o import budou podobně nedokonalé.
changed the description
Vyrobte mi prosím nějaké miniCSV jako proof-of-concept, na kterém to mohu replikovat, případně opravit/nareportovat.
ok, přiložen je jeden ze souborů který používám pro import. Formát XLS je podporovaný pro import, nemusí být CSV. Má záložky, což je podporované, ale umí to importovat vždy jen první záložku. Takže pokud chceme importovat jinou záložku, je potřeba ji v Excelu posunout na první místo a soubor uložit. Pak znovu importovat.
Nyní vysvětlím proč jsem začal používat zrovna tuto strukturu pro import organizací: Je to vesměs proto, aby to respektovalo strukturu zápisu položek Orgsanizací, jakou používá Sahana. Ta struktura je taková "specifická" a pořád se snažím chápat důvod.
Zde mi v XLS první záložka s obecnými názvy *název slouží jako top-level rozcestník pro Organizace, které mohou být v jedné oborové skupině Organizací.
Na první záložce v XLS tedy nejsou žádná další kontaktní data. Když má XLS tabulka prázdná pole, tak to nevadí.
Samotný import první záložky probíhá bez problémů. Komplikace ovšem vzniká, když do Organizací chci opakovaně importovat další XLS záložky s dalšími Organizacemi.
Pokud bych je chtěl mít všechny v top-level řazení, pak není problém. Jejich import se provede.
Takový import ale začne mít uživatelský problém, že v hlavní tabulce je velké množství Organizací v 1. úrovni. Dlouhý seznam.
Toto množství je pak extrémně nepřehledné ve všech jiných částech Sahany, kde se vybírá z drop-downu Organizace.
Sahana nabízí pro strukturování (mimo jiné) možnost vytvořit podřízenou organizaci. Anglicky Branch. A to i v několika úrovních. Ta je v importní šabloně definována sloupci Branch, SubBranch, SubSubBranch.
Podle unikátního názvu ve sloupci "Name" se pak tyto Organizace importují rovnou jako podřízené té top-level organizaci. Tato podřízenost se dá zadat i ručně, ale pouze po jednotlivých organizacích výběrem z formuláře. Ruční činnost by u velkého množství byla strašně otravná a pomalá. Proto je cílem připravit tabulku tak, aby dokázala importovat data rovnou tak, aby byla rozdělena do podřazených větví.
Vhodná podřazenost Organizací je vidět jako srozumitelnější výpis v hlevní tabulce Organizací. Respektive ty podřazené v ní nejsou vidět vůbec, ale pokud použiji filtr, dají se vyfiltrovat.
V jiných modulech se na toto řazení Organizací používá i stromová struktura s rozbalovacími prvky, kde je takové třídění také užitečné.
No, to je zhruba vysvětleno proč jsem se pustil do strukturovaného importu Organizací.
Nyní zpět k začátku, kdy jsem importoval první úroveň Organizací z 1. záložky XLS.
Následný import 2. záložky XLS však odhalí další "vlastnost" Sahany. Je to "přírůstkový" import dat, tj. pokud Sahana objeví, že se mu shoduje "Name" ve sloupci, tak import přidá k položce, která už v DB je. Doplní prázdná místa. Pokud má více řádek identické "Name" ale rozdílné Branch, tak se přírůstkově importnou buňky do této top level položky. Tim se bohužel zabije vymyšlená struktura, která se snaží respektovat jak je to v Sahaně vymyšleno se strukturou Organizací.
Tím se bohužel stane, že moje top level položka *NNO po importu obsahuje vyplněné buňky z druhého importu, které by měly být v samostatné podřízené položce. Ale nejsou.
Abych tomuto zamezil, rozhodl jsem se vyplnit všechny buňky zástupným znakem "." aby je Sahana chápala jako vyplněné a tudíž je nedoplnila přírůstkem.
Tento nápad se moc nevydařil. Sahana už po těch letech umí lépe odhalovat chyby v importních datech, ale přesto i zde došlo k padání a ticketům, z kterých je patrné, že v polích které musí mít konkrétní znaky, nako např. telefon mít číslice v telefonním tvaru, e-mail musí mít @ a url musí mít nějaký protokol http://
Importer to tedy jaksi umí něco naimportovat, ale jakmile dojde k následnému vstoupení do jednotlivé položky (formulář Organizace) tak vzniknou nové komplikace: Formulářová pole obsahují "." ale takový formulář už nejde uložit, protože evidentně je vyplněn chybně. Položka Organizace nejde ani smazat. Jsem v koncích.
Takže shrnuto:
vývojáři asi nějak laborují s používáním prázdných buněk, jejich interpretací jako "None" a následně z toho vzniklých problémů... Já tomu moc nerozumim. Jen opakovaně vidím tikety.
dávkový import XLS se chová divně, když chci importovat Branch do existující nadřízené struktury Organizací. Zde vznikla nějaká změna od minule, protože dříve jsem dokázal dokončit strukturu jak chci, teď jsem zas zmatený, protože se to chová jinak.
dávkový import v porovnáním s ručním zadáváním dat nemají identicky přísný filtr proti možným chybám. Z toho plyne že se dají importovat chybná data a následně je pak těžké se jich ručně zbavit. Nebo je opravit.
výše vypsané problémy importu jsem popsal na importu Organizace, ale je možné, že se v podobné míře vyskytují i při jiných importech např. Offices nebo Facility. (Pro Office i Facility mam další importní data, jsou lehce jiná podle typu šablony) Princip bude podobný.
poslední a podstatný problem je, že špatně/omylem importovaná data je nemožné efektivně odstranit.
Sahana se laicky řečeno chová tak, že má "tisíc pravidel jak přesně má importovat data". Fajn. Jakmile ale nějaká data naimportujeme špatně, tak je pro správce dat extremně náročné, nebo nemožné je stejně rychle smazat. V editoru DB to padá. Bavíme se o stovkách, nebo tisících DB řádek.
Najednou se objevují hlášky o nemožnosti smazání dat, protože existují cizí závislosti. Nebo rovnou padání do ticketů. Fran to už myslím vysvětloval, že je důležité neohrozit integritu DB...
To je sice jasné, že cizí závislosti na mazaných DB datech existují, ale není z toho cesta ven.
Takový způsob importu dat, kdy nesmím udělat jedinou chybu, jinak je vše špatně a nevratné, je pro správce dat velmi WTF... uživatelsky jsme se správou dat docela v řiti.
3_Organizace_CZ.xls
kdyby vás napadlo jak jim to tumočít, budu vděčný. Já neumím formulovat report v terminologii Pythonu. Díky.
Mno, obávám se že změn ve struktuře importů je mnohem více. To znamená že vzniklo spoustu nových chyb, nových problémů které byly předtím vpořádku a nesrozumitelných chování. Neustále nějaké tickety.
Budu se v tom muset zase postupně hrabat, předělávat tabulky s daty a zkoušet furt dokola.
Vůbec nevím kde začít aby to bylo možné nějak tlumočit.
Paráda. Instanci jsem smazal, tj. s tím zmizely i odkazy na Tickety. Budu to hlásit znovu.
Vítejte v mém světě. :) Tohle je přesně to, co jsem měl na mysli, když jsem říkal, že touhle dobou by projekt potřeboval celého dalšího člověka na opravy regresí. A také se obávám, že tohle je přesně to, co nakonec umoří osla, pokud každého půl roku strávíme týdny na prozkoumávání opravách věcí, které F&B za tu dobu zase stihli rozbít. Na jejich velmi chatrnou obhajobu bych podotkl, že za posledního půl roku v kódu proběhlo mnoho změn, které měly za úkol zlepšit kompatibilitu s pythonem 3. Tohle se mělo dělat už před lety, nicméně se s tím začalo jen pár měsíců předtím, než byla ukončena podpora pythonu 2, takže to je celé šité horkou jehlou a podle toho to taky vypadá.
Tak nějak tuším, že to nebude zas tak černé a že většina problémů s importem bude mít společnou příčinu.
Pokud možno, přiložte vždy nějaký replikovatelný postup. Ticket samotný sice obsahuje cenné informace, ale když nevím, jak se k nim dospělo, opravu to značně ztíží. Také pomůže, pokud stejný postup vyzkoušíte na Demo instanci s výchozím templatem, abychom rozlišili, zda se jedná o chybu způsobenou naší customizací nebo jestli k ní dochází i v základu.
Jojo, já to chápu. oba máme už notnou WTF zkušenost, každý trochu jinou. Ale já to nevzdávám a pustím se do toho :)
zdá se, že moje výše vypsané lamento souvisí s tím, že Struktura hierarchií kontaktů se dá nově "konfigurovat" právě s pomocí Wizzardu. A to já jsem si ještě nemohl vyzkoušet a zjistit co je výsledkem.
Je možné, že východiskem bude používat jednodušší strukturu, kde nebude nutné komplikovaně vytvářet zástupné organizace. Trochu se obávám množství neošetřených chyb.
Pořádně a poctivě jsem si přečetl popis toho Vašeho workflow a budu tu za ďáblova advokáta. Berete to za špatný konec. Tohle je přesně jedna ze záležitostí, kterou nám F&D pořád vytýkají a zároveň i jedna ze záležitostí, ve kterých Sahana vyniká, pokud se s ní člověk dokáže dostatečně skamarádit.
Vy totiž v tomhle bodě máte naprosto přesnou představu, jak by ta hierarchie, třídění, řazení a vyhledávání mělo fungovat a snažíte se jej napasovat na model, který s něčím takovým nepočítá a problém neřeší, ale naopak jej komplikuje. Místo rovnání vohejbáků bychom si měli napsat vlastní komponentu, která nám zprostředkuje takový pohled na data, který v našem kontextu dává smysl jak při jejich zadávání, tak i při práci s nimi. Tady by se třeba IMHO hodilo, aby to celé fungovalo následovně:
Příklad: Z CSV importů
org:
org_office:
pak vypadne struktura
Která bude takto vidět ale pouze při výběru organizace ve formulářích, kde je potřeba nějakou organizaci vybrat. V organizacích bude vidět jen Org1 a Org2 a pokud uživatel bude chtít jen konkrétní typ, dá se vyfiltrovat.
Dále - Ty pomlčky jakožto zástupná prázdná data jsou určitě špatně. To nedává smysl ani z pohledu významu těch hodnot (prázdná data mají být prostě prázdná) ani z pohledu validace, na které Vám to celkem očekávatelně selhává. To že by to mělo selhat nějak přívětivěji než pádem na tlamu je trochu jiný problém. Budu se mu věnovat.
Tohle je tak trochu problém vejce a slepice. Sahana má při importu krok, ve kterém je možno se na importovaná data podívat ještě před potvrzením importu. To že import selže i přesto, že náhled neselhal je problém aplikace (kterému se budu věnovat), nikoliv dat, takže není relevantní, jestli jsou to tisíce řádků nebo jen tři. Další věc je, že se u importu na ostrou instanci předpokládá, že správnost dat již bude ověřena. Aplikace má možnost ověřit datové typy jednotlivých polí a existenci cizích klíčů, ale nemá jak ověřit faktickou správnost, takže pokud import projde a všechna omezení jsou splněna, pak na úrovní aplikace, databáze a jejich modelů není důvod cokoliv vracet zpátky nebo si "pamatovat" stav před importem. Jakým způsobem byste si představoval, že má mít správce možnost mazat? Z hlediska integrity systému jako celku by takový nepovedený/vadný import měl být rollbackován na nějaké o hodně nižší úrovni - tj. třeba snapshot databáze nebo celé VM. Nemyslím, že tohle je u jiných aplikací nějak zásadně jiné. Třeba když do ODK uploadnete vyplněné formuláře, tak je tam prostě máte a šmytec.
Jop, taky budu řešit. Ve #408.
mentioned in issue #417
Přiznávám, moje myšlení v tomhle poněkud klopýtá za jejich návrhem aplikace. Ale snažím se abych deficit dohnal a přijal to. Už netoužím měnit jim architekturu, úplně by stačilo kdybych eliminoval ty zásery :)) (moje trvání na datech vycházelo z toho, jak jsem se dostával k datasetům z Českého prostředí a nebyl jsem schopen je napasovat do Sahany, v době kdy tam nefungovalo ještě víc věcí než funguje teď. Proto jsem vymýšlel kraviny. A konkrétně jejich položky Type a Sector a další třídící parametry dřív Sahaně nefungovaly, nebo přinejmenšim chování v GUI a importu bylo rozdílné a matoucí.
Lhostejno že programátorsky to ASI nemělo chybu.
ještě si projdu co píšete... teď jen v rychlosti: Zatím nenavrhujte žádnou naší customizaci. Moje chyby určitě přiznávám, ale oni je mají a měli taky.
poslední k DB importům... argument chápu. Můj nářek je hlavně pro situaci, kdy nejde objektivně o chybná data, ale jde o lidský omyl při importování. Sahana díky své správě přístupových práv umožňuje aby různí lidé byli schopni něco dovnitř natáhnout. Když někdo udělá omyl až do fáze importu, už se nevrátí zpátky a pravděpodobně tak silně ovlivnil sroyumitelnost již obsažených dat. Aby takový svůj omyl odhalil, tak bude muset dělat mnoho treninkových importů.
V této situaci by se z toho hlavní správce dat brzy obreslil, protože by nestíhal dělat snapshoty a backupy. Kdyby je nedělal, zas by narostlo riziko že dat bude mnoho a duplicitních... A likvidace duplicit, nebo dávkové mazání je v Sahaně velmi oserné, nebo špatné.
jak říkáte... slepice, nebo vejce. Nenaděláme nic :)
moje 50 cents rada pro vývojáře by byla: Udělejte DEMO šablony s vyplněnými daty...Jedině VY víte nejlíp co je správně. Nebo je někde prezentujte aby to bylo na první pohled jasné. Tím uživatelům obrovsky pomůžete. Jenže tohle je pod rozlišovací schopnost F+D protože jim to je jasné, viditelné rovnou ze záhlaví šablon, a zbytek se dá dohledat ve zdrojácích importeru.
Prošel jsem si ty importy... a je to nejspíš ještě daleko horší než čekáte.
Takže vlastně vůbec nevím, zda tam ty importy by design slouží i k něčemu jinému než k iniciálnímu naplnění dat při instalaci template.
Tahle chyba nejspíš existuje jen ve Spotter template. V defaultu nevidím žádné pole, které by žralo celočíselné proměnné.
Na
ValueError: unknown url type: '.'jsem otevřel upstream issue #1554, společně s dotazem na ty ostatní chybějící hodnoty (t.j. třeba ten rok u organizací), ale čekám zas odpověď ve stylu "Nejsou to hodnotná data ve workflow. Nasrat."mentioned in issue #438
OK. Odpověď ve skutečnosti byla "Nejsou to hodnotná data ve workflow. Jestli je chcete, pošlete si PR.", což je nejspíš ta lepší varianta. Takže jsem si na import roku založení organizací poslal cvičné PR #1555.
stav se šablonami jste popsal docela přesně, jako jsme už udělali pozorování před lety. Mam tu na to i zpracovaný XLS, který jsem se svými poznámkami dokonce i posílal Franovi k posouzení. Myslím že odpověď byla zhruba ve smyslu: "ano, tak to je". Proto také část mých pokusů byla strašně časově náročná a nefektivní, protože mi nešlo odhalit proč nelze data do Sahany dostat importem a lze je dostat ručně. A naopak...
zrovna rok vzniku organizace neni zásadní informace pro data.
Kdyby bylo na mne, tak zásadní informace je unikátní identifikátor organizace, což je IČ. A také datová schránka. To jsou ple, které by pak musely být i v DB a v rozhraní, aby to dávalo smysl.
Daly by se nalézt další bullshity, které už mám objevené, jako např. nekonzistentní názvy jednotlivých csv šablon. Příklad: #238
Zrovna tohle PR nemá až tolik co dělat s tím, jestli jde o zásadní data nebo ne. To je spíš takové politické oťukávání, jak moc velké (resp. malé) věci nám v PR projdou. Mám pocit, že v tomhle kole jsme našli celkem dobrou rovnováhu mezi reportováním bugů, reportováním kokotin a posíláním PR. Prostě je to celé o tom, že na F&D musíme udělat dojem, že se snažíme a oni se pak budou snažit taky. I když to budou nějaké zdánlivě nevýznamné maličkosti.
A tohle je přesně to, co potřebuje vědět programátor, který se bude zabývat customizací "Vašeho" template, protože tohle jsou oboje věci, které je možno celkem snadno doimplementovat.
(uvnitř budou už neaktuální poznámky, některé templaty se změnily) takže jen přikládám, není to v tuto chvíli zadání.
SE_TEMPLATES__overview.xlsx
Reportovaný problém opraven v upstreamu i na VM.
closed