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.