Dotaz: Java 8 - Data Access vs. Entity Framework

[Max]

Ahoj,
měl bych jeden amatérský dotaz (nejsem programátor).
V jobu máme Oracle db a začíná se pomalu programovat pod C#. Aby se ulehčila komunikace s DB, tak se využívá Entity Framework (EF). Vypadá to pomale, i když novější verze EF mají mít výkonností vylepšení. Pro větší akce se to zdá nepoužitelné (rozdíly jsou v sekundách). Navíc vždy s novější verzí EF se musí čekat, až Oracle vydá aktualizaci svého ODAC pro novější EF. Další problém je, že dost verzí EF bylo mezi sebou nekompatibilních, takže přechodu na novější verzi následoval částečný přepis.
Narazil jsem na zajímavé info o Java a revolučnímu databázovému přístupu, viz :
Java 8 Will Revolutionize Database Access
+ tento výkřik :
Does Java 8 Still Need LINQ? Or is it Better than LINQ?
Na první pohled vypadá v jave 8 práce s SQL podobně jako v Entity Frameworku. Zajímalo by mně, zda to někdo nepoužíváte a jak je to rychlé? Když se na to dívám okem laika, tak mi přijde, že java 8 má v tomto nemalý náskok.
Díky
Zdar Max

---

---

Odpovědi

[Radek Miček]

Vypadá to pomale, i když novější verze EF mají mít výkonností vylepšení.

V jakém smyslu? Že trvá, než EF vygeneruje SQL dotaz, nebo že vygenerované SQL dotazy jsou neefektivní a ručně by je šlo napsat lépe?

Když se na to dívám okem laika, tak mi přijde, že java 8 má v tomto nemalý náskok.

V principu nevidím žádný rozdíl. Co vám přijde tak dobré?

Nicméně s typovou bezpečností na tom bude hůře jOOQ, naráží totiž na omezenost Javy – např. na absenci anonymních záznamů, takže následující dotaz

Result<Record3<String, String, String>> result =
create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
      .from(BOOK)
      .join(AUTHOR)
      .on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
      .where(BOOK.PUBLISHED_IN.equal(1948))
      .fetch();

vrací trojice, kde k prvkům přistupujete buď pomocí getValue např.

r.getValue(AUTHOR.FIRST_NAME)

Jenže, co když se zeptáte na pole, které není součástí výsledku? Dostanete výjimku IllegalArgumentException. Proto je tu druhá možnost – přístup přes pozici

r.value2()

Jenže, co když někdo například změní pozici autorova jména? Navíc, pokud bude výsledek obsahovat více než 4 sloupce, bude takový kód těžko čitelný.

Na druhé straně v C# můžete vytvořit nový anonymní typ

new { BookTitle = ..., AuthorFirstName = ..., AuthorLastName = ... }

a pak jednoduše psát

r.AuthorFirstName

a kód je přehledný a bezpečný (kompilátor zachytí, když napíšete r.Year, kde Year není součást výsledku).

[Ivan]

Tak jsem koukal na ten Jinq. Jestli to to dobre chapu tak oni vytvori lambda, zkoupiluji ji do bytecode, pak ten bytecode zanalyzuji a vytori z nej SELECT. A to vsechno jenom proto, aby se programatori nemuseli ucit SQL? No prominte mi ten flame, ale jejich starosti bych chtel mit.

Pokud mate problem s vykonem tak nakonec vzdycky skoncite u SQL a exekucnich planu, s tim ne neda nic delat. Z toho co jsem za vsechny to roky videl, tak castejsi problem je v tom, ze tyhle frameworky nepodporuji producer-consumer design pattern, a tak tahaji kazdy zaznam zvlast, takze to nakonec nedrhne na vykonu databaze, ale mnozstvi round-tripu mezi klientem a databazi. Objektovy pristup se da tezko napasovat na davkove zpracovani dat v SQL.

Docela by me zajimalo jak se ten Jinq da pouzit na inicialzaci, nejaky komplexnejsi hierarchie trid. (Zvlast kdyz JDBC podporuje pouze skalarni datove typy).

[Marek]

+1, pokud nekdo vazne resi vykon, pak nema smysl nic jineho nez optimalizovany SQL dotaz

[Radek Miček]

A to vsechno jenom proto, aby se programatori nemuseli ucit SQL?

Obecné výhody nástrojů tohoto typu: Kusy dotazů jde používat opakovaně (fragment dotazu jde použít ve více dotazech), nevzniká problém SQL injection, můžete používat stejný dotaz pro databázi, pro kolekce aj.

Jazyky se silnějšími typovými systémy pak umožňují dotazy parametrizovat tabulkami, názvy polí apod. Například můžete vytvořit typově bezpečné administrační rozhraní, které funguje pro libovolnou tabulku. Pak ho použijete:

(* Deklarace tabulky. *)
table t1 : {Id : int, A : int, B : string, C : float, D : bool}
  PRIMARY KEY Id

(* Vytvoříme administrační rozhraní pro tabulku t1. *)
open Crud.Make(struct
                   val tab = t1
                             
                   (* Titulek stránky. *)
                   val title = "Crud1"
                               
                   (* Typy a názvy sloupců. *)
                   val cols = {A = Crud.int "A",
                               B = Crud.string "B",
                               C = Crud.float "C",
                               D = Crud.bool "D"}
               end)

[Filip Jirsák]

Odolnost proti SQL injection není výhoda těchto nástrojů, je to standard. Naopak se bohužel stále ještě používají nástroje, které k SQL injection přímo vedou. Výhoda stejného dotazu pro databázi jako pro kolekce mi připadá trochu zvláštní, pokud někdo ty dotazy pouští nad kolekcemi, asi nepotřebuje SQL databázi. Obecně mi tyhle nástroje na vytváření SQL dotazů připadají jako narovnáky na vohejbáky.

[Radek Miček]

pokud někdo ty dotazy pouští nad kolekcemi, asi nepotřebuje SQL databázi

Kolekce se hodí třeba v testech. Nebo má data v databázi a pak ještě v nějaké službě přístupná třeba přes OData. Všude může používat stejné dotazy.

[Radek Miček]

Nebo má kolekci, která funguje jako cache.

[Filip Jirsák]

A ve všech těchto případech asi nepotřebuje SQL databázi, protože v SQL databázi bude mít nejspíš spousty tabulek provázaných přes identifikátory, zatímco v kolekci bude mít záznamy jednoho typu, ze kterých bude podle nějakých kritérií vybírat. Ano, SQL databáze se dá použít i k uložení takové kolekce, ale je to okrajový případ, a především pozůstatek doby, kdy se data dala v zásadě uložit buď do souboru nebo do SQL databáze. Nepřipadá mi ale šťastné pro takové okrajové řešení vytvářet speciální frameworky.

Stručně řečeno, tenhle typ ORM nástrojů se hodí tam, kde se jako technologie chybně zvolila SQL databáze.

[Radek Miček]

Stručně řečeno, tenhle typ ORM nástrojů se hodí tam, kde se jako technologie chybně zvolila SQL databáze.

To vůbec nemusí být ORM (sám nejsem příznivcem ORM), zmínil jsem třeba Ur/Web – tam jde primárně o korektnost a redukci kódu. Navíc tam nejsou žádné objekty.

SQL je beztypový jazyk a korektnost kódu vám staticky nepohlídá. Rovněž je tam těžké kód použít opakovaně. Proto je vhodnější použít jiný jazyk.

[Filip Jirsák]

Vhodnější by to bylo, pokud by tím jazykem mluvil přímo databázový server.

Tyhle nástroje sice mohou pohlídat, že vytvoří syntakticky správné SQL, ale to neříká vůbec nic o tom, zda ten SQL příkaz půjde opravdu spustit. Za největší problém považuju to, že ty nástroje zpravidla umí jenom nějakou podmnožinu SQL podporovaného serverem, takže pokud potřebujete něco speciálnějšího (což při optimalizacích typicky potřebujete), skončíte stejně u slepování textů. Navíc složitější dotazy bude stejně vytvářet někdo, kdo aspoň trochu rozumí databázi, a napíše je v SQL – takže ve výsledku pak někdo musí SQL dotaz přepsat do tohohle speciálního jazyka, aby to pak nějaký nástroj slavnostně přepsal zpět do SQL. A všichni doufají, že z toho vznikne ten původní dotaz.

[Matlák]

SQL je beztypový jazyk

uf. Asi jsi nikdy nedělal s postgresem?

[Ivan]

Ok SQL ma typy ale.. Byly doby, kdy se predpokladalo, ze SQL bude takova jednodussi anglictina a ze to budou pouzivat vsichni. Proto standart pozaduje aby existovala implicitni konverze mezi stringem a datumem anebo mezi stringem a cislem. K cemu to pak vede to vime vsichni co SQL skutecne pouzivame.

[Radek Miček]

Můžete dát příklad, co přesně myslíte? Probíhá tam typová kontrola před spuštěním SQL skriptu?

[Matlák]

Myslím třeba kontrolu shodnosti typů při psaní SQL dotazů. V postgresu nejde napsat WHERE sloupec = 5 když typ sloupce je varchar a naopak nejde napsat WHERE sloupec = 'ahoj' když sloupec je číselného typu. Vyhodí to výjimku, tedy pokud pomocí "::" hodnotu nepřetypujete (ovšem musí jít přetypovat že).

[Radek Miček]

V postgresu nejde napsat WHERE sloupec = 5 když typ sloupce je varchar a naopak nejde napsat WHERE sloupec = 'ahoj' když sloupec je číselného typu. Vyhodí to výjimku

Důležité je, kdy se to děje. Jestli se to děje až za běhu SQL skriptu, tak to není typový systém. Podle knihy Types and Programming Languages je typový systém:

A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

…

Another important element in the above definition is its emphasis on classification of terms—syntactic phrases—according to the properties of the values that they will compute when executed. A type system can be regarded as calculating a kind of static approximation to the run-time behaviors of the terms in a program.

Typový systém tedy počítá statickou aproximaci chování programu. Např. Python žádný typový systém nemá, neboť před spuštěním programu se tam žádná aproximace jeho chování nepočítá.

Nicméně máte pravdu v tom, že některé implementace SQL typovou kontrolu v určitých situacích dělají (např. při kompilaci uložených procedur), nevím však, zda je to součástí standardu?

[OldFrog {Ondra Nemecek}]

No nevím, doteď jsem žil v domění že typovost a okamžik vazby jsou dvě rozdílné věci:

• dynamic/late binding versus
• strong/weak typing

[Radek Miček]

Staticky se myslí "bez spuštění programu".

No nevím, doteď jsem žil v domění že typovost a okamžik vazby jsou dvě rozdílné věci

Ano, jsou to různé věci. O vazbě jsem nic nepsal.

[OldFrog {Ondra Nemecek}]

Dobře, takže máme statický a dynamický typový systém? V tom případě mi přijde, že typový systém ztotožňujete pouze se statickým. Nebo jsem to blbě pochopil?

[Radek Miček]

V tom případě mi přijde, že typový systém ztotožňujete pouze se statickým.

Ano, přesně tak.

[OldFrog {Ondra Nemecek}]

No a Smalltalk nebo ObjectiveC nemá tedy typový systém?

[Radek Miček]

Smalltalk ne (alternativně lze říci, že má triviální typový systém s jedním typem – viz Dynamic Languages are Static Languages), Objective-C ano (neboť podporuje statictké typování).

Můj postoj vysvětluje například Andreas Rossberg nebo Norman Ramsey v odpovědích na Does “untyped” also mean “dynamically typed” in the academic CS world?

[Matlák]

Důležité je, kdy se to děje. Jestli se to děje až za běhu SQL skriptu, tak to není typový systém.

Mno, definovat podle tohohle SQL jako beztypové mi připadá trochu přehnané. To můžu rovnou říct že ten jazyk nemá žádnou syntaxi, protože se správnost syntaxe ověřuje až při spuštění. Když se typy zjišťují před spuštěním operace, je to pořád rozlišování typů.

"Beztypové" chování by pak mohlo být něco ala MySQL kde se typy implicitně převádějí (a maximálně vyhodí nějaké varování) a operace (zápis například) proběhne vždy bez ohledu na to, že typy nesouhlasí, a v nemálo případech se tak prostě na disky ukládají zmrzačené, popřípadě žádné informace.

[rADOn]

Když se typy zjišťují před spuštěním operace…

Kdysi davno se SQL psalo primo do kodu a nejakej preprocesor z toho vybuildil rovnou kod na strachani se v datovych souborech. Tomu by se dalo rikat "typovy" pacz mohl strilet chyby uz pri kompilaci. Ano, mas pravdu, mysql se obcas chova kokotsky… ale pokud jedinej rozdil je ze ti misto jedny vyjimky vystreli jina, tak to neni silne typovy. To bys stejne mohl rikat ze je silne typovy python - interpret te taky posle do prdele kdyz mu podstrcis „1 + 'foo'“.

[Matlák]

ale pokud jedinej rozdil je ze ti misto jedny vyjimky vystreli jina, tak to neni silne typovy.

Pravda, ovšem MySQL výjimku nevyhodí, pouze varování (a to jen někdy) a prostě zapíše vždy, klidně i NULL. Výjimka by byla v takové chvíli požehnání, protože se dá odchytit a zobrazit chybová hláška, popřípadě zalogovat. Považuju "Fail early" za hodně důležité a typovost (ať už slabá či silná) tomu pomáhá.

BTW Diskuse byla pouze o přídomku "beztypový", nikoliv "silně" či "slabě typový" jazyk. SQL se mi prostě jako "beztypové" nezdá. Toť vše.

[DarkKnight]

Vsechno je o tom, jestli dany databazovy server umite spravovat. http://dev.mysql.com/doc/refman/5.6/en/sql-mode.html

[OldFrog {Ondra Nemecek}]

Zkušenost nemám ani s jedním (v javě používám ActiveJDBC), nicméně bych podotkl, že orm nástroje často umožňují:

• ovlivňovat která data se načtou hned a která líně (lazy and eager)
• použít klasické sql (a s výsledkem pak už pracovat dle běžných zvyklostí orm nástroje)
• sdružovat operace do dávek
• použít cache

Mají tyhle možnosti kolegové nastudované a vyzkoušené? Rychlost prostě zásadní měrou záleží na způsobu použití, velikosti dat, nastavení... a a bez bližšších údajů případně profilleru lze těžko říct, zda by bylo něco jiného rychlejší.

Ještě ohledně Java 8, jinq, stream api - když pominu to, že tam lze snadno paralelizovat, tak hlavní přínos je IMHO v něčem jiném, než v tom, že by to mělo být nějak automaticky superychlé nebo to z programátora sejmulo nutnost nad rychlostí přemýšlet

[Tomáš]

Zdravím

Myslím, že vůbec nezáleží na tom jestli C# nebo Java. Klíč k výkonosti vidím spíše v pojetí ORM knihovny. Co očekávám od ORM knihovny? Dotazy vrací objekty, které podporují lazy loading a vrácené objekty (pokud mají unikátní klíč) jsou zapisovatelné . Prakticky vypadá lazy loading takto:

Person.address

se transparentně propíše jako

 select … from ADDRESS A where A.PERSON_ID = :PERSONID 

a vytvoří se nová kolekce objektů adressa a vloží se do atributu Person.address. Zapisovatelnost objetů lze ukázat na příkladě:

Person.name = "pepin";

se mi propíše (na požádání nebo na konci transakce) na:

update PERSONS P set NAME='pepin',… where P.ID =…

Pokud má tyto požadavky ORM knihovna splňovat, tak jsou dvě cesty jak takových požadavků dosáhnout:

1. Knihovna vrací proxy objekty. Příkladem jsou Hibernate/NHibernate, Entity Framework, … a 90% všech ostatních ORM.
2. Knihovna vrací potomky nějakého generického ORM objektu. Nad ní jsou přes dědičnost definovány property (getter/setter) pro přístup k datům. Typickými zástupci této skupiny jsou Cayenne, Ujorm, Enterprise Objects Framework, Active JDBC. Žádný .NET ORM tohoto druhu neznám.

Nyní se pokusím ukázat k jakým neblahým koncům vede přístup číslo 1. Metody (DAO) objektu (a ani jeho potomci) nemohou přímo přistupovat k vlastním datům(!). Kdyby metody udělaly, tak obejdou lazy loading hook implementovaný v proxy objektu. Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu. Programátoři si pro kopírování dat ulehčují práci a vznikají knihovny jako Automapper a jim podobné. Architektura je pak ukázkovým příkladem lasagne code a ke všemu se většinou nezadržitelně stává i kódem s Ravioli strukturou. Samotný kód business logiky pak tvoří pouze minoritní část, zbytek kódu je balast. Bezuzdné kopírování dat (deep copy) a vytváření objektů pak dává pěkně zabrat alokátoru paměti a garbage collectoru. Spotřeba paměti stoupá do závratných výšin a operations oddělení posiluje HW

Další negativa proxy přístupu jsou jen kyselou špičkou na proxy ledovci:

• typeof(vytvořený_DAO_objekt) vrací Proxy. Drobnost, která komplikuje zdánlivě jednoduché situace.
• Obtížná práce s detached objekty. Množství výsledků google dotazu na LazyInitializationException asi mluví za vše.

Abych nebyl úplně jednostranný, tak zkritizuji i druhou cestu.

• Nefunguje code first přístup. Třídy DAO jsou generovány z modelovacího nástroje, které obvykle nepodporují verzování s možnostmi tfs/svn/git. Diff souborů modelovacího nástroje je většinou nepoužitelný a merge změn v generovaných DAO objektech se pak skoro nedá udělat. Řešení existují, ale zatím elegance code first nedosahují.
• Protože nefunguje code first, tak nejdou dobře dělat inkrementální změny v databázi na bázi kódu. popis knihovny C# a knihoven Java.

Žádná z výtek k cestě 2, ale nemá vliv na výkonnost a udržovatelnost aplikace. To že se nedá jít cestou code first a jde se cestou model first, já osobně považuji spíše za plus, protože se snáze odchytí pokřivené datové modely. Například teď jsem narazil na jeden projekt s přístupem code first, kde místo vazeb 1:N vytvářeli vazby M:N (s vazební tabulkou), protože jejich (homemade) ORM nepodporovalo vazby 1:N. Přirozeně taková chyba má velmi negativní výkonostní dopad a absence podstatných integritních kontrol v databázi navíc vytváří prostor pro datové chyby, které následně i vznikají. Osobně považuji důslednou kontrolu datového modelu jako velmi účiný a jednoduchý způsob jak zabránit zásadním chybám při analýze a následném vývoji SW. Taková kontrola se u přístupu database first mnohem lépe dělá.

Ale zpět k dotazu C# vs. Java. To jestli se bude psát dotaz jen s pomocí konstrukcí Java 1.4 v Cayenne ( rok 2005 )

  SQLTemplate q = new SQLTemplate(Person.class, "select * from PERSON where name ='pepin'");
  // SelectQuery q = new SelectQuery(Person.class, ExpressionFactory.Equal(Person.nameProperty,"pepin")); // anti sql injection version
  List p = ctx.peformQuery(q);

nebo LINQ ( rok 2007 )

  var query = from p in person
            where (p.name = "pepin")
            select p;

nebo ve stylu Java 8 ( rok 2014 )

  Person.stream().filter(s-> s.name="pepin");

považuji spíše za kosmetické než revoluční změny vedoucí ke zvýšení výkonu. Klíče k výkonné a udržovatelné aplikaci leží totiž úplně jinde.

Mimochodem, asi jste zaregistrovali, že příklad z Cayenne je nejstarší - circa z roku 2005. Příklad pro Enterprise Objects Framework by byl ještě o 10 let starší, tedy cca z roku 1996(!).

[OldFrog {Ondra Nemecek}]

1+ hezky rozebráno, něco jsem se dozvěděl

[Radek Miček]

Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu.

Anemický model není antipattern – je velmi přirozené jednotlivé věci oddělit a zvýšit znovupoužitelnost kódu. Naopak splácat vše do jedné třídy je antipattern.

[Matlák]

Tohle je otázka - mně jako vývojáři na jednu stranu vyhovuje, když mám vrstvy oddělené a můžu třeba i jednoduše vyměnit databázový framework (s IoC kontejnery je to velmi snadné), navíc se hodí mít pro cachování jinou sadu objektů než pro práci s DB, na druhou stranu to co napsal Tomáš o tunách "balastkódu" a hromadou mapování (třeba takový Dozer - už ten název napovídá, že jde o buldozer na shrabování ohromných hromad objektů ) je pravda.

Lehké frameworky typu Cayenne (třeba český Ujorm) jsou v tomhle lepší, nepotřebují tolik objektů - ale na druhou stranu je pak návrh aplikace s nimi těsně svázán, přechod na jiný framework je velmi obtížný, je tu problém s cachováním a serializací a pokud chcete mít v aplikaci více API pro různé účely, nakonec se hlubokému kopírování a mapování stejně nevyhnete.

[rADOn]

Hezky rozepsany. Me z toho plyne ze je to vzdycky neco za neco, a pro cloveka ktery si umi napsat dotaz je orm celkem k nicemu.

[OldFrog {Ondra Nemecek}]

Spíš naopak Když umím sql, nemám problém s orm (které mi může ušetřit dost práce).

[rADOn]

No ja v zadnym z tech prikladu co jsi psal zase tolik usetreny prace nevidim. Spis praci zametenou pod koberec. Nemuset priblble opisovat fetchnuti hodnot do atributu objektu je bezva, imo cokoliv slozitejsiho ma stejnej pocet problemu jako vyhod. Treba liny dotahovani je pro me ve vetsine pripadu nevyhoda, pacz to nafukuje transakce a muze to drazdit deadlocky, takze nakonec klicovy casti stejne budu psat rucne (s execution planem v ruce). ORM mi muze pomoct nabouchat prototyp, ale pokud mi bude stat v ceste pri ladeni vykonu tak to zase tolik prace neusetri, jen ji to presune nekam kde to neni hned videt. BTW proto taky vsechny ORM co jsem videl se v prvni rade kasaji jak umi krasne jednoduse nabouchat administracni rozhrani – protoze to je uloha kde na efektivite zase tolik nezalezi.

Disclaimer: jsem zaujatej pacz od javy jsem utekl, v Cecku jen veci kde na vykonu hodne zalezi a v pythonu jsou tyhle debaty vicemene smesny…

[OldFrog {Ondra Nemecek}]

Souhlasím s tím, že záleží případ od případu - pročež jsem ostatně řekl, že ORM práci ušetřit „může“.

[Max]

Pánové, jen bych chtěl poděkovat za podnětnou diskusi, která mně torchu zasvětila do problematiky a objasnila několik věcí.
díky
Zdar Max