Ako (ne)používať stromy v djangu

4.5.2018 10:38 | Přečteno: 1916× | Programovanie | poslední úprava: 18.5.2019 18:37

Existuje mnoho knižníc pre django, ktoré riešia ukladanie stromov do relačnej databázy. Najpoužívanejšie sú django-mptt a django-treebeard. Doteraz som vždy používal django-mptt. Keď django-cms prešlo z mptt na treebeard rozhodol som sa, že začnem používat treebeard aj ja.

Prehľad spôsobu uloženia

django-mptt

Táto knižnica používa pre uloženie stromu 5 polí. Konrétne je to parent_id, lft, rght, level, a tree_id. Podrobne vysvetlený význam atribútov lft a rght je v tomto blogu. Výber podstromov, rodičov, ciest ... je pri tomto type stromu veľmi elegantný. Na druhej strane modifikácia stromu je dosť zložitá.

djang-treebeard

Treebeard implementuje niekoľko spôsobov uloženia stromu. Pozrime sa na preferovaný teda materialized path. V tabuľke nám pribudnú polia path, depth a numchild. Cesta sa skladá z ascii znakov, ktoré sa líšia v závislosti od použitej databázy. Cesty teda vyzerajú takto: 0000 (prvá položka), 0001 (druhá položka), 00010000 (prvý potomok druhej položky). Výbery sa uskutočňujú pomocou operátora LIKE. Inserty môžu vyžadovať prepísanie značnej časti ciest ak sa uskutočňujú blízko koreňa v hornej časti stromu. Vkladanie hlboko do stromu je pomerne rýchle.

Skúsenosti

S django-mptt pracujem dlho. Je to odskúšaná, stabilná, dobre zdokumentovaná knižnica. Na problémy s výkonom som ja osobne nenarazil, ale nerobím nič tak náročné, kde by sa to malo prejaviť. V dokumentácii je upozornenie na nutnosť obaliť operácie do transakcie (treba na to dávať pozor inak sa budú diať zlé veci).

Dokumentácia django-treebeard mi neprišla ktovie ako užitočná. V čase písania blogu bola neaktuálna a nereflektovala zmeny v zdrojových kódoch, takže som väčšinou skončil pri čítaní zdrojových kódov namiesto dokumentácie.

Prvý závažný problém, na ktorý som pri django-treebeard narazil na produkčnom serveri bolo zoradenie. Totiž používali sme slovenské texty a databáza mala nastavená collation na slovenčinu. Tá má však také špecifiká ako "CH", takže sa zoradenie podľa path rozbilo na prvý pohľad nepochopiteľným spôsobom. Varujem teda všetkých, ktorí by chceli použíavať django-treebeard - skontrolujte si na serveri collation pre stĺpec path, v prípade potreby ho zmnňte (ALTER TABLE tabulka ALTER path TYPE character varying(255) COLLATE "C"; v postgrese).

API django-treebeard je podľa mňa miestami obskurné, miestami nepoužiteľné a miestami oboje. Ako príklad uvediem rendervoanie stromu v šablóne - django-treebeard. Atribút close je pekne obskurný a ako bonus obsahuje čísla 0..n (teda nie level ktorý daný záznam zatvára). Vďaka tomu nie je možné napríklad vyrenderovať strom, ktorý by mal v druhej úrovni trochu inú štruktúru než v prvej. Pre titeto prípady som si musel napísať filter, ktorý do close doplní level.

@register.filter_tag
def add_level(items):
    for __, info in items:
        info['close'] = [info['level'] - c for c in info['close']]
    return items

Pre porovnanie django-mptt to má vyriešené pomocou tagu recurstree, takže nie je potrebné nič dohackovať.

Ďalej som dnes zistil, že django-treebeard nie je schopný vyrenderovať formulár s vlastným layoutom (to fakt nikto za tú dobu nepotreboval?), pri zobrazení formulára generuje cez 10 000 selectov (ah hlanve, že sa autor chváli benchmarkami) ...

Moje odporúčanie teda znie - kašlite na to, čo je práve populárne. Používajte radšej to, čo je dobré. Ja zatiaľ skúsim pretlačiť pár svojich úprav do django-treebeard ;)

       

Komentáře

[Josef Kufner]

Stromy v SQL databázi pomocí Nested Sets (parent_id, tree_left, tree_right, tree_depth, a tree_root_id) používám dlouho a funguje to skvěle. Není to stavěné na časté vkládání a modifikace obecně, ale jinak to je velice elegantní a praktický způsob uložení stromu, který umožňuje jedním selectem vytáhnout cokoliv je potřeba – podstrom, všechny rodiče ke kořeni, potomky, sousedy.

Teoreticky sice stačí jen left a right, ale je robustnější používat primárně parent_id, na kterém není co zkazit, a ty ostatní 4 hodnoty si dopočítat. Hloubka se hodí pro jednodušší vykreslování stromu. ID kořene pak umožní optimalizovat aktualizace left a right při úpravách stromu (pokud je v DB mnoho malých stromů je pak rychle, neboť se přepočítá jen jeden).