Dotaz: FP - Ako ukladať komplexné typy

[hermes]

Čaute, keď programujete funkcionálne a používate špeciálne typy (napr. Result, Option alebo custom algebraické typy), a potrebujete ich serializovať (do databázy, alebo súboru, poslať niekam na REST), konvertujete ich najprv na nejakú jednoduchšiu štruktúru (napr. obyčajné plain objekty / štruktúry alebo polia), aby sa dali uložiť ako JSON? Alebo ich ukladáte priamo — aj so zachovaním algebraických typov — jedna k jednej? Napríklad cez MessagePack, alebo upravený JSON/BSON/XML serializer?

Lebo otázka je: čo vlastne ukladať — a či tú štruktúru nezjednodušiť. Získa sa tým flexibilita: vkladanie dát bude jednoduchšie, zobrazenie dát bude jednoduchšie (nemusím to prechádzať rekurzívnou funkciou a zložito renderovať) môžem tam vložiť aj veci ktoré by som inak nevložil, ale zabije sa tým typová kontrola, a vlastne všetko čo som použitím komplexných typov získal nie? A tiež v SQL DB sa tým zabije možnosť robiť SQL dopyty nad JSON (vačšina SQL DB umožnuje pracovať so stĺpcom ako s JSONom ale pochybujem že okrem JSON podporujú aj MessagePack)

Odpovědi

[X]

Zeptam se jako FP lama. To je skolni uloha, nebo to ma nejake realne uplatneni?

[Robin]

Ve funkcionalnim programovani se databaze bere za dalsi externi system. Mel bys mit explicitni serializaci a deserializaci (vcetne validace). Ta serializace muze byt totozna jako pro DTO (Data transfer object), ktery bys posilal jinym sluzbam.

Kazdopadne se neukladaji typy jako Result nebo Option, ty slouzi pouze pro vnitrni beh programu.

[OldFrog {Ondra Nemecek}]

Podle mě je jedno, zda jde o FP nebo ne, FP do rozhodování nepřináší žádná zvláštní kritéria.

MessagePack se podle mě v obecném případě nevyplatí - důvodem je malá podpora a sporadický přínos. Určitě nedávat jako formát pro výměnu dat, JSON s kompresí bude mít podobné vlastnosti a je široce podporovaný.

V databázi lze JSON dobře použít. Např. v Postgresql můžete udělat indexy a pak se rychle dotazovat. Můžete udělat funkcionální indexy. Nebo entity namapujete na několik tabulek a získáte referenční integritu, transakce apod. vše v režiji databáze. Ve většině případů to je lepší, než se snažit si to implementovat v aplikační logice.

Souhlasím s tím, abyste ukládat přímo entity, nikoli obalové hodnoty typu Optional, Result apod.

[BoneFlute]

nemusím to prechádzať rekurzívnou funkciou a zložito renderovať

Zajímalo by mě, proč ti něco takového přijde složité.

či tú štruktúru nezjednodušiť

Zjednodušení je dobrá věc. Ale v případě databáze jde o to, že ty to tam budeš chtít uložit ale pak zase načíst a získat stejný výsledek. Ledaže by ti to zjednodušení pomohlo při práci v rámci té databázi.

napr. Result, Option alebo custom algebraické typy

První úvaha je, že Result, či Option nahradíš Null hodnotou. Jenže pokud budeš ukládat strukturu, která jako nějaký prvek obsahuje Result/Option, tak ti to přestane dávat smysl.

konvertujete ich najprv na nejakú jednoduchšiu štruktúru (napr. obyčajné plain objekty / štruktúry alebo polia), aby sa dali uložiť ako JSON?

Ano, používám JSON, protože k tomu se dostane i databáze.

Úplně nerozumím, co je v kontextu FP myšleno jednodužší struktura. Každá struktura FP krom lambd jsou jedna ku jedné převoditelné na něco v JSON. A pokud parser zná typ, tak se tam v mnoha případech dají vypustit typy a tak maximálně tam přilípnout discriminanty...