Alternativa k Hibernate

anonym

Alternativa k Hibernate
« kdy: 19. 07. 2018, 16:14:49 »
Na Hiebrnate a podobnych frameworcích se mi líbí ta možnost popsat pomocí tříd tabulky v databázi, kde následně se ty tabulky i automaticky podle těch tříd vytvoří. Další věc co se mi líbí je elegantní OOP ukládání dat do DB, nemusím psát ručně inserty.

Co se mi ale nelíbí hodně moc, tak to je dotazování. Prostě není nad to mít data v relační DB a udělat si pořádný SQL dotaz, když chci něco specifického natáhnout. Kus logicky se tak přenese do elegantního SQL dotazu, místo aby se psala logika filtrace dat v Javě.

SQLko je jedna z mála technologií, která je prostě 100% solidní, kažždý, i projekt manager nebo tester, SQL umí a přijde mi, že to prostě nechci obcházet nějakýma nadstavbama z Hibernate.

Další problém s Hibernatem je rychlost, která je násobně horší než čisté SQL.

Takže se chci zeptat, jak vlastně elegantně pracovat s databízí s co nejmenší nadstavbou a přitom abych:

1. Při insertování dat nemusel psát ručně SQL inserty.
2. Měl nějak elegantně definované schéma, ideálně v OOP, aby se tabulky v DB automaticky vytvořily pokud ještě neexistují.
3. Neměl v projektu pro každou kombinaci SELECTu vytvořené stovky tříd vždy pro ten jeden typ dat.


MarSik

Re:Alternativa k Hibernate
« Odpověď #1 kdy: 19. 07. 2018, 16:57:37 »
Zajímavou alternativou by mohly být různé DSL knihovny jako třeba http://www.querydsl.com/ nebo http://www.jooq.org/. Umožňují lepší kontrolu nad generovaným SQL a mají typovou kontrolu pomocí vygenerovaných tříd pro entity/tabulky.

Hibernate má tu (ne)výhodu, že se get() občas zvrhne v načítání celého světa a update se bez get nedá udělat. Spousta funkcí ale nepotřebuje kompletní data entity pro změnu jednoho sloupce (například).

L.

Re:Alternativa k Hibernate
« Odpověď #2 kdy: 19. 07. 2018, 17:39:03 »
Hibernate ale má svůj HQL, ne?

Re:Alternativa k Hibernate
« Odpověď #3 kdy: 19. 07. 2018, 18:08:01 »
Je běžné, že ORM frameworky podporují i ručně zapsané dotazy - buď přímo SQL nebo něco co se mu podobá.  Nebo lze použít typesafe query. Možností je obecně mnoho, výběrem můžete strávit mnoho času:

https://ebean-orm.github.io/ https://cayenne.apache.org/ http://jdbi.org/ https://www.jooq.org/ https://github.com/my2iu/Jinq https://github.com/speedment/speedment https://github.com/knowm/Yank https://github.com/requery/requery https://github.com/tzaeschke/zoodb http://www.querydsl.com/ http://javalite.io/activejdbc http://joist.ws/ http://www.sormula.org/home/ https://github.com/dieselpoint/norm http://ormlite.com/ ... a tuny tuny dalších.

Nezáludný minimalistický je třeba http://javalite.io/activejdbc a zkouším teď něco s https://ebean-orm.github.io/ který má zase (pro určité projekty) výhodu v tom, že je z hlediska uživatele sessionless a umí jak Active record tak i Data mapper přístup a umí TypeSafe queries. V http://jdbi.org/ zase napíšete sql do anotací, což je pak docela přehledné a na jednom místě. Každé řešení má něco... Musíte mít dost zkušeností, abyste věděl, co si pro daný účel vybrat. Pro větší projekty s více lidmi použijte něco hodně vyzrálého a zavedeného, hodnoťte stáří projektu, počet odkazů na netu, úroveň dokumentace, šíři funkcí, podporované databáze, podporu různých API stylů a taky podporu nových verzí javy (stream api apod.). Pak jsou ještě taková hodně obsáhlá řešení typu DataNucleus nebo ArangoDB apod. Ale chcete něco spíš minimalistického, takže to nechávám stranou.

Youda

Re:Alternativa k Hibernate
« Odpověď #4 kdy: 19. 07. 2018, 23:41:58 »
Hibernate samozřejmě podporuje native queries, sam to tak pouzivam, jenom jako mapper na entity beany. Hromada entity beanu neni problem, eclipse generator ti jich nasere kybl a mas inheritni kontrolu dat.
Generovat SQL z jawy je hodne blby napad, zapomen na nejake rozumne integritni omrzeni apod, pripadne views apod.

Pro inserty osobne pouzivam stored procedury,  mam pak navic jistotu, ze nikdo  neudela nic, co nechcu, sam si ridim transakce.


SB

Re:Alternativa k Hibernate
« Odpověď #5 kdy: 20. 07. 2018, 10:09:53 »
Pro inserty osobne pouzivam stored procedury,  mam pak navic jistotu, ze nikdo  neudela nic, co nechcu, sam si ridim transakce.

Jak zajišťují uložené procedury, že "nikdo  neudela nic, co nechcu"? Jaký mají uložené procedury vliv na transakce?

JmJ

  • ****
  • 302
    • Zobrazit profil
Re:Alternativa k Hibernate
« Odpověď #6 kdy: 20. 07. 2018, 15:27:37 »
Zazil sem hibernate a bohuzel sem zazil ve velke mire i entity framework od MS. Tyto technologie jsou k nicemu, neusetrili mi nikdy nic, naopak trpi tolika problemy, ze cas vyvoje byt jen trochu slozitejsi aplikace se jimi vzdy prodlouzil. Neexistuji zadne "best pracites", konkretne u entity frameworku jsme skupinove venovali nemaly cas tomu, abychom pochopili jak s nim spravne pracovat. Nepochopil to nikdo, protoze ta vec neni urcena k normalni praci. Code first zapis postrada zcela banalni funkcionality, dotazy neumi temer nic atd. Vyhoda toho, ze jsou data odtrzena on konkretni implementace db padne hned po te, co zjistite, ze bud muzete napsat nativni dotaz, nebo 5 hodin hledat reseni neceho, co v SQL mate za 10 minut. Jako by ten framework nikdo nikdy ani poradne nepouzil. Programovani se misto vymysleni reseni zmeni ve vymysleni rovnaku na ohejbaky a ohybani hlavni casti aplikace tak, aby bylo s pristupem k datum pomoci "datove frameworku" co nejmene problemu.

Zahodte to, pouzijte normalni spojeni na SQL server, mejte zvlast definici tabulek v SQL a zvlast tridy nesouci data a pouzijte rovnou nativni SQL dotazy a budete mi klid a mir v dusi a vse pod kontrolou.

anonym

Re:Alternativa k Hibernate
« Odpověď #7 kdy: 20. 07. 2018, 16:05:11 »
Zazil sem hibernate a bohuzel sem zazil ve velke mire i entity framework od MS. Tyto technologie jsou k nicemu, neusetrili mi nikdy nic, naopak trpi tolika problemy, ze cas vyvoje byt jen trochu slozitejsi aplikace se jimi vzdy prodlouzil. Neexistuji zadne "best pracites", konkretne u entity frameworku jsme skupinove venovali nemaly cas tomu, abychom pochopili jak s nim spravne pracovat. Nepochopil to nikdo, protoze ta vec neni urcena k normalni praci. Code first zapis postrada zcela banalni funkcionality, dotazy neumi temer nic atd. Vyhoda toho, ze jsou data odtrzena on konkretni implementace db padne hned po te, co zjistite, ze bud muzete napsat nativni dotaz, nebo 5 hodin hledat reseni neceho, co v SQL mate za 10 minut. Jako by ten framework nikdo nikdy ani poradne nepouzil. Programovani se misto vymysleni reseni zmeni ve vymysleni rovnaku na ohejbaky a ohybani hlavni casti aplikace tak, aby bylo s pristupem k datum pomoci "datove frameworku" co nejmene problemu.

Zahodte to, pouzijte normalni spojeni na SQL server, mejte zvlast definici tabulek v SQL a zvlast tridy nesouci data a pouzijte rovnou nativni SQL dotazy a budete mi klid a mir v dusi a vse pod kontrolou.

Tak tohle je zajímavá zkušenost a mě to tak taky trochu přijde. Jenže pak je tady takový problém a sice jak udělat třeba Cache?

Já bych teda Cache nejraději nepoužíval, protože mám z minulého projektu takové tušení, že tam přidává nedeterministický prvek - nechápu jak se zajistí SERIALIZABLE, když se něco Cachuje, a zaroven nevim proc bych mel pouzivat jinaci izolaci, nez Serializable. Nicmene hodne lidi bude chtit cache pouzivat. Jak z toho ven?

kraxna

Re:Alternativa k Hibernate
« Odpověď #8 kdy: 20. 07. 2018, 16:21:54 »
Zazil sem hibernate a bohuzel sem zazil ve velke mire i entity framework od MS. Tyto technologie jsou k nicemu, neusetrili mi nikdy nic, naopak trpi tolika problemy, ze cas vyvoje byt jen trochu slozitejsi aplikace se jimi vzdy prodlouzil. Neexistuji zadne "best pracites", konkretne u entity frameworku jsme skupinove venovali nemaly cas tomu, abychom pochopili jak s nim spravne pracovat. Nepochopil to nikdo, protoze ta vec neni urcena k normalni praci. Code first zapis postrada zcela banalni funkcionality, dotazy neumi temer nic atd. Vyhoda toho, ze jsou data odtrzena on konkretni implementace db padne hned po te, co zjistite, ze bud muzete napsat nativni dotaz, nebo 5 hodin hledat reseni neceho, co v SQL mate za 10 minut. Jako by ten framework nikdo nikdy ani poradne nepouzil. Programovani se misto vymysleni reseni zmeni ve vymysleni rovnaku na ohejbaky a ohybani hlavni casti aplikace tak, aby bylo s pristupem k datum pomoci "datove frameworku" co nejmene problemu.

Zahodte to, pouzijte normalni spojeni na SQL server, mejte zvlast definici tabulek v SQL a zvlast tridy nesouci data a pouzijte rovnou nativni SQL dotazy a budete mi klid a mir v dusi a vse pod kontrolou.

To zni jako ze jste se Hibernate v dusledku moc nenaucili (nic ve zlym). Hibernate neni problem pouzit na jakkoliv slozite databazi, ale clovek musi 1) si o tom neco precist prvne 2) premyslet 3) sledovat, co vlastne po hibernate chce.

99% problemu s hibernate je o tom, ze (taky)programator pouziva hibernate stylem, ze predstira, ze tam zadna databaze neni a to je samozrejme cesta do pekla.

Codefirst se hodi na mensi, jednoduche databaze - celkem prekvapive to neumi vse, co DDL v SQL. Ale da se to velmi jednoduse zkombinovat pomoci SQL skriptu (ktery hibernate spousti pri vytvareni schematu) a nebo nejlepe code first vubec nepouzivat, on k tomu v dusledku neni moc zadny duvod.

Stejne tak JPQL/HQL - povazovat to za nahradu SQL je zcela fundamentalni chyba. Je to uzitecny nastroj pro jednoduche dotazy, pro slozite je potreba pouzit nativni dotazy, mapovani result setu, vytvaret DTO pro mapovani vysledku.

Sila Hibernate je v tom, ze usetri velke mnozstvi casu pri vytvareni entit, CRUD operaci, mapovani jednoduchych dotazu - ale zaroven zachovava veskerou flexibilitu primeho pristupu k DB.

Ale snaha nepouzit tuto flexibilitu u pripadu, kde je to potreba, je presnym opakem toho, jak se ma Hibernate pouzivat.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Alternativa k Hibernate
« Odpověď #9 kdy: 20. 07. 2018, 16:27:26 »
Zazil sem hibernate a bohuzel sem zazil ve velke mire i entity framework od MS. Tyto technologie jsou k nicemu, neusetrili mi nikdy nic, naopak trpi tolika problemy, ze cas vyvoje byt jen trochu slozitejsi aplikace se jimi vzdy prodlouzil. Neexistuji zadne "best pracites", konkretne u entity frameworku jsme skupinove venovali nemaly cas tomu, abychom pochopili jak s nim spravne pracovat. Nepochopil to nikdo, protoze ta vec neni urcena k normalni praci. Code first zapis postrada zcela banalni funkcionality, dotazy neumi temer nic atd. Vyhoda toho, ze jsou data odtrzena on konkretni implementace db padne hned po te, co zjistite, ze bud muzete napsat nativni dotaz, nebo 5 hodin hledat reseni neceho, co v SQL mate za 10 minut. Jako by ten framework nikdo nikdy ani poradne nepouzil. Programovani se misto vymysleni reseni zmeni ve vymysleni rovnaku na ohejbaky a ohybani hlavni casti aplikace tak, aby bylo s pristupem k datum pomoci "datove frameworku" co nejmene problemu.

Zahodte to, pouzijte normalni spojeni na SQL server, mejte zvlast definici tabulek v SQL a zvlast tridy nesouci data a pouzijte rovnou nativni SQL dotazy a budete mi klid a mir v dusi a vse pod kontrolou.

Tak tohle je zajímavá zkušenost a mě to tak taky trochu přijde. Jenže pak je tady takový problém a sice jak udělat třeba Cache?

Já bych teda Cache nejraději nepoužíval, protože mám z minulého projektu takové tušení, že tam přidává nedeterministický prvek - nechápu jak se zajistí SERIALIZABLE, když se něco Cachuje, a zaroven nevim proc bych mel pouzivat jinaci izolaci, nez Serializable. Nicmene hodne lidi bude chtit cache pouzivat. Jak z toho ven?

nestačí ti cache na úrovni http a cache na úrovni databáze?

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Alternativa k Hibernate
« Odpověď #10 kdy: 20. 07. 2018, 16:33:18 »
Hibernate neznám, ale ORM používám. Jak v čistém SQL píšete DRY joiny?

anonym

Re:Alternativa k Hibernate
« Odpověď #11 kdy: 20. 07. 2018, 16:33:48 »
Hoši já nevím, je to složité a proto mi přijde naprd to ještě zesložiťovat Hibernatem. Vezměte si třeba tu Cache, ten Hibernate si to nějak cachuje, ale jak? A když nevíte jak, tak jak můžete vědět, že zachováte 100% serializovatelnost transakcí? A když to na 100% nevíte, protože do toho Hibernate nevidíte, tak jak to můžete používat? Já bych se na to nejraději úplně vysral a použil něco jako je MyBatis. A nemusím nic řešit. Nakonec, když mám pořádnou DB, tak si tam stejně dám Liquibase.

anonym

Re:Alternativa k Hibernate
« Odpověď #12 kdy: 20. 07. 2018, 16:35:59 »
A navíc ušetřím několik megabajtů na knihovnách a hezkých pár desítek megamabjtů na vyžrané RAM.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Alternativa k Hibernate
« Odpověď #13 kdy: 20. 07. 2018, 16:55:46 »
A když to na 100% nevíte, protože do toho Hibernate nevidíte, tak jak to můžete používat?

do databáze také nevidíš.

kraxna

Re:Alternativa k Hibernate
« Odpověď #14 kdy: 20. 07. 2018, 17:23:40 »
Hoši já nevím, je to složité a proto mi přijde naprd to ještě zesložiťovat Hibernatem. Vezměte si třeba tu Cache, ten Hibernate si to nějak cachuje, ale jak? A když nevíte jak, tak jak můžete vědět, že zachováte 100% serializovatelnost transakcí? A když to na 100% nevíte, protože do toho Hibernate nevidíte, tak jak to můžete používat? Já bych se na to nejraději úplně vysral a použil něco jako je MyBatis. A nemusím nic řešit. Nakonec, když mám pořádnou DB, tak si tam stejně dám Liquibase.

Hibernate Caching je 1) transakcni 2) zdokumentovany 3) na serializovatelnost transakci nema vliv (a pokud jo, tak jsi to mel stejne blbe i predtim - klasicky priklad s nekorektne pouzitym READ COMMITTED).

Nic proti MyBatis, je fajn, klidne ho pouzivej, ale tohle mi prijde jako zbytecne (a neopravnene) plivani spiny na Hibernate