SLICK

A ještě po úplnost: Na ETN dev-blogu mi vyšel další článek: Tentokrát o SLICKu – ne-ORM nástroji pro práci s databázemi.

Flattr this!

This entry was posted in DB, Scala. Bookmark the permalink.

5 Responses to SLICK

  1. Jiří Knesl says:

    Nevíte, jestli existuje něco podobného i pro Clojure? Tedy možnost pracovat s databází jako s obyčejnou datovou strukturou.

    • O ničem nevím, ale když vezmu v potaz jak je Clojure flexibilní jazyk (+makra samozřejmě), nepochybuji, že něco takového existuje/vzniká.

  2. v6ak says:

    Jiří Knesl: To nevím, ale neměl by být problém k tomu napsat wrapper, pokud se Clojure spustí nad JVM:

    • Scala se kompiluje do celkem přirozeného bytecode. Výjimkou jsou speciální znaky v identifikátorech, například znak ‚=‘ se přeloží jako „$eq“, ‚#‘ se přeloží jako „$hash“ apod. Metoda s názvem „someValue_=“ (tedy běžný setter ve Scale) se přeloží jako „someValue_$eq“. Bližší představu lze získat pomocí nástroje javap.
    • Interoperabilita Clojure s JVM tu je: http://clojure.org/java_interop
    • Nezkoumal jsem to moc, ale možná i Clojure bude umět Scalovské konvence se speciálními znaky ($eq, $hash, $plus, …) a půjde to ještě přirozeněji.
    • Lambda funkce jsou ve Scale scala.FunctionN, kde N je počet parametrů. Tuto část wrapperu bych ale psal spíše ve Scale. Obecně všechny Scalové traity (možná bude pár výjimek) je lepší implementovat ve Scale. Nebo můžeme udělat abstract class AbstractFunction2[-T1, -T2, +R] extends Function2[T1, T2, R] a dědit z AbstractFun­ction2.
    • Možná bude potřeba řešit implicití konverze, které Scala používá, ale Slicku se to nejspíš netýká.
    • Rozhodně by to šlo, JVM konec konců mluví jedním jazykem, ale nejsem si jistý jestli by to šlo tak jednoduše. SLICK se někde dost spoléhá na implicitní magii a to by se v Clojure, jak dynamickém jazyce, muselo nějak rafinovaně emulovat.

      • v6ak says:

        Já myslel, že právě Slick moc implicitní konverze nepotřebuje. Ty používá dost Squeryl, ale u Slicku jsem myslel, že by se bez nich obešel.

        Pak bych je spíš řešil v tom wrapperu ručně nebo je nechal vyřešit Scalovým kompilátorem. Psát automatické konverze pro Clojure by byl overkill – možná pro programátora a celkem určitě pro CPU, protože Clojure by to muselo řešit dynamicky za běhu, ne při kompilaci.

        Navíc v dynamickém jazyce tyto automatické konverze mohou fungovat jen omezeně (neznáš typy parametrů). To by na 95 % tady nebyl problém (vzlášť při volání Scalového kódu), ale je dobré s tím počítat.

Leave a Reply

Your email address will not be published. Required fields are marked *