Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: anonym 19. 07. 2018, 16:14:49

Název: Alternativa k Hibernate
Přispěvatel: anonym 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: MarSik 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).
Název: Re:Alternativa k Hibernate
Přispěvatel: L. 19. 07. 2018, 17:39:03
Hibernate ale má svůj HQL, ne?
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: Youda 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: SB 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?
Název: Re:Alternativa k Hibernate
Přispěvatel: JmJ 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 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?
Název: Re:Alternativa k Hibernate
Přispěvatel: kraxna 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: gll 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?
Název: Re:Alternativa k Hibernate
Přispěvatel: gll 20. 07. 2018, 16:33:18
Hibernate neznám, ale ORM používám. Jak v čistém SQL píšete DRY joiny?
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 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.
Název: Re:Alternativa k Hibernate
Přispěvatel: gll 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íš.
Název: Re:Alternativa k Hibernate
Přispěvatel: kraxna 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
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 20. 07. 2018, 17:52:06
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

Caching u Hibernate klidne muze byt transakcni, ale ne vuci jine nezavisle connection do Databaze. Ta Service muze byt ledasco, muze to byt nejaka periodicky poustena ulozena procedura, muze to byt trigger, muze to byt nejaky programator ktery zrovna opravuje databazi manualne. Kdyz pouzivas Cache, automaticky porusujes Serializable na urovni databaze.
Název: Re:Alternativa k Hibernate
Přispěvatel: BoneFlute 20. 07. 2018, 19:08:07
Nakonec, když mám pořádnou DB, tak si tam stejně dám Liquibase.
Ale Liquibase nijak nesouvisí ani s ORM, ani s kešováním, ne? Liquibase je na verzování změn db.
Název: Re:Alternativa k Hibernate
Přispěvatel: kraxna 20. 07. 2018, 19:16:53
Caching u Hibernate klidne muze byt transakcni, ale ne vuci jine nezavisle connection do Databaze. Ta Service muze byt ledasco, muze to byt nejaka periodicky poustena ulozena procedura, muze to byt trigger, muze to byt nejaky programator ktery zrovna opravuje databazi manualne. Kdyz pouzivas Cache, automaticky porusujes Serializable na urovni databaze.

Logicky pokud je neco NEZAVISLA connection do databaze, tak ma logicky NEZAVISLE transakce. Hibernate samozrejme tyhle veci resi pomoci XA transaction, pokud mas sdilenou transakci pres vice connection (do ruznych db), tak se synchronizuje pres XA.

Ale pokud tvuj argument znel,ze kdyz pouzijes cache, tak ze se ti rozbije v pripade, ze nekdo neco zmeni a neinvaliduje cache, tak vznika rozpor, tak to je samozrejme pravda, ale v takovem pripade nemuzes pouzivat vubec zadnou cache :-D
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 20. 07. 2018, 19:21:08
Nakonec, když mám pořádnou DB, tak si tam stejně dám Liquibase.
Ale Liquibase nijak nesouvisí ani s ORM, ani s kešováním, ne? Liquibase je na verzování změn db.

Ale souvisí s tím, jakým způsobem se bude definovat databáze, ne modelovýma třídama jako u hibernate, ale sqlkem.
Název: Re:Alternativa k Hibernate
Přispěvatel: Franta <xkucf03/> 20. 07. 2018, 22:26:28
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?

Samy o sobě nijak, ale obvykle se používají v souvislosti s tím, že máš v DB víc uživatelů, a ten, pod kterým tam chodí aplikace má jen omezená práva, není vlastníkem objektů a nemůže dělat INSERT, UPDATE atd. a může jen volat ty procedury + SELECTy na určitých tabulkách.

Co se týče transakcí, ty bych do procedur většinou nedával a řešil je vně – tak, aby si transakci mohl řídit ten, kdo to volá a nebylo to zadrátované v proceduře. Výjimkou je logování, které se dělá v autonomní transakci (zalogováno chci mít vše, i když se na konci udělá ROLLBACK a/nebo vyletí nějaká výjimka) a některé speciální případy.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 20. 07. 2018, 22:55:34
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?

Samy o sobě nijak, ale obvykle se používají v souvislosti s tím, že máš v DB víc uživatelů, a ten, pod kterým tam chodí aplikace má jen omezená práva, není vlastníkem objektů a nemůže dělat INSERT, UPDATE atd. a může jen volat ty procedury + SELECTy na určitých tabulkách.

Co se týče transakcí, ty bych do procedur většinou nedával a řešil je vně – tak, aby si transakci mohl řídit ten, kdo to volá a nebylo to zadrátované v proceduře. Výjimkou je logování, které se dělá v autonomní transakci (zalogováno chci mít vše, i když se na konci udělá ROLLBACK a/nebo vyletí nějaká výjimka) a některé speciální případy.

Čili v podstatě uděláš to, co musí být uděláno, a to na úrovni databáze - tzn. k databazi se pristupuje jen a pouze pres nějáký centrální program. V SOA když je databáze, do které pčistupují různé Service, tak to rovněž nemůžou dělat napřímo - prostě to nelze kvůli zamykání a bordelu - ale přistupují tam přes centrální service.

Procedury v DB budou OK pro něco malého, ale složitější business logiku nějaké banky bych si v tom neuměl představit psát, to je nanic, a lepší je to dát do centrální Java service. A ještě lepší je, nechat každou Service aby měla vlastní DB a žádnou centrální "DB která vládne všem" nedělat. Je to proto, že v té centrální Service je zákonitě bordel jako prase, protože do ní všechny týmy zapisují. Takhle má každý tým svůj vlastní chlíveček za který si odpovídá sám.
Název: Re:Alternativa k Hibernate
Přispěvatel: Franta <xkucf03/> 21. 07. 2018, 00:32:50
Procedury v DB budou OK pro něco malého, ale složitější business logiku nějaké banky bych si v tom neuměl představit psát, to je nanic, a lepší je to dát do centrální Java service.

Celkem vtipné, protože tohle je běžná praxe řady systémů. Neříkám, že je to optimální (nový systém bych taky psal primárně v té Javě), ale rozhodně to není nic nepředstavitelného a v praxi to (byť s nějakými problémy) funguje. Je třeba brát v úvahu, v jaké době ty systémy vznikaly – dnes se běžně používají systémy, jejichž návrh je deset a víc let starý. Někdy je to myšlenkově nebo i reálně staré dvacet let. Nakonec můžeš být rád, že to není psané v COBOLu :-)
Název: Re:Alternativa k Hibernate
Přispěvatel: L. 21. 07. 2018, 17:01:27
Procedury v DB budou OK pro něco malého, ale složitější business logiku nějaké banky bych si v tom neuměl představit psát, to je nanic, a lepší je to dát do centrální Java service.

Celkem vtipné, protože tohle je běžná praxe řady systémů. Neříkám, že je to optimální (nový systém bych taky psal primárně v té Javě), ale rozhodně to není nic nepředstavitelného a v praxi to (byť s nějakými problémy) funguje. Je třeba brát v úvahu, v jaké době ty systémy vznikaly – dnes se běžně používají systémy, jejichž návrh je deset a víc let starý. Někdy je to myšlenkově nebo i reálně staré dvacet let. Nakonec můžeš být rád, že to není psané v COBOLu :-)

Jojo, taky jeden takový systém znám.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 12:16:37
Zkoušel jsem si jak by to vypadalo s JDBC a nepřijde mi to vůbec špatné:



Kód: [Vybrat]
public class DbUtil {

    public static <T extends ResultSetModel> List<T> resultSet(T model, ResultSet rs) throws SQLException, IllegalAccessException, InstantiationException {
        List<T> ret = new ArrayList<>();
        while(rs.next()) {
            Object[] rowArr = getRowAsArray(rs);
            model.setFromRow(rowArr);
            ret.add(model);
        }
        return ret;
    }

    public static Object[] getRowAsArray(ResultSet rs) throws SQLException {
        int colCnt = rs.getMetaData().getColumnCount();
        Object[] ret = new Object[colCnt];
        for(int i = 0; i < colCnt; i++) {
            ret[i] = rs.getObject(i+1);
        }
        return ret;
    }


    public static ResultSet executeQuery(String sql, ConnStm conn) throws InterruptedException, SQLException {
        PreparedStatement st = null;
        ResultSet rs = null;
        try {
            st = conn.getPrepStat(sql);
            rs = st.executeQuery();
        } catch (SQLException e) {
            throw e;
        }

        return rs;
    }

    public static <T extends ResultSetModel> List<T> executeQuery(String sql, T model, ConnStm conn) throws SQLException, InterruptedException, InstantiationException, IllegalAccessException {
        return resultSet(model, executeQuery(sql, conn) );
    }
}


Kód: [Vybrat]
public interface ResultSetModel {
    public void setFromRow(Object[] row);
}

@Data
@ToString
public class Timeline implements ResultSetModel {
    private Timestamp measured_timestamp;
    private String keyword_name_fid;
    private Integer amount;
    private String special;

    @Override
    public void setFromRow(Object[] row) {
        int i = 0;
        measured_timestamp = (Timestamp) row[i++];
        keyword_name_fid = (String) row[i++];
        amount = (Integer) row[i++];
        special = (String) row[i++];

    }
}



A staci mi pak udelat:

Kód: [Vybrat]

@AllArgsConstructor
public class TimelineDao {
    final static String findAll = "SELECT * FROM TIMELINE";

    public List<Timeline> findAll(ConnStm conn) throws Exception {
        return DbUtil.executeQuery(findAll, new Timeline(), conn);
    }
}



Akorat jeste nevim, jak dopravit do DAOcka Connection jinak, nez pres parametr metody. Takhle totiz muzu snadno zaridit, aby mi kazdy jeden request probehl v jedne transakci.

Takhle vypadá moje DI:

Kód: [Vybrat]

@Data
public class App {

    DatasourcePool datasourcePool;
    DataService dataService;
    LoginService loginService;
    RestApi restApi;
    TimelineDao timelineDao;


    public App() throws Exception {
        initProperties();

        datasourcePool = new DatasourcePool(
                "org.postgresql.Driver",
                System.getProperty("jdbc.connection"),
                System.getProperty("jdbc.user"),
                System.getProperty("jdbc.password")
        );
        timelineDao = new TimelineDao();
        dataService = new DataService(timelineDao);
        loginService = new LoginService();
        restApi = new RestApi(dataService, loginService, datasourcePool);
    }


Start na Tomcatovi je za 700ms.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 28. 07. 2018, 13:33:24
Zkoušel jsem si jak by to vypadalo s JDBC a nepřijde mi to vůbec špatné:



Kód: [Vybrat]
public class DbUtil {

    public static <T extends ResultSetModel> List<T> resultSet(T model, ResultSet rs) throws SQLException, IllegalAccessException, InstantiationException {
        List<T> ret = new ArrayList<>();
        while(rs.next()) {
            Object[] rowArr = getRowAsArray(rs);
            model.setFromRow(rowArr);
            ret.add(model);
        }
        return ret;
    }

    public static Object[] getRowAsArray(ResultSet rs) throws SQLException {
        int colCnt = rs.getMetaData().getColumnCount();
        Object[] ret = new Object[colCnt];
        for(int i = 0; i < colCnt; i++) {
            ret[i] = rs.getObject(i+1);
        }
        return ret;
    }


    public static ResultSet executeQuery(String sql, ConnStm conn) throws InterruptedException, SQLException {
        PreparedStatement st = null;
        ResultSet rs = null;
        try {
            st = conn.getPrepStat(sql);
            rs = st.executeQuery();
        } catch (SQLException e) {
            throw e;
        }

        return rs;
    }

    public static <T extends ResultSetModel> List<T> executeQuery(String sql, T model, ConnStm conn) throws SQLException, InterruptedException, InstantiationException, IllegalAccessException {
        return resultSet(model, executeQuery(sql, conn) );
    }
}


Kód: [Vybrat]
public interface ResultSetModel {
    public void setFromRow(Object[] row);
}

@Data
@ToString
public class Timeline implements ResultSetModel {
    private Timestamp measured_timestamp;
    private String keyword_name_fid;
    private Integer amount;
    private String special;

    @Override
    public void setFromRow(Object[] row) {
        int i = 0;
        measured_timestamp = (Timestamp) row[i++];
        keyword_name_fid = (String) row[i++];
        amount = (Integer) row[i++];
        special = (String) row[i++];

    }
}



A staci mi pak udelat:

Kód: [Vybrat]

@AllArgsConstructor
public class TimelineDao {
    final static String findAll = "SELECT * FROM TIMELINE";

    public List<Timeline> findAll(ConnStm conn) throws Exception {
        return DbUtil.executeQuery(findAll, new Timeline(), conn);
    }
}



Akorat jeste nevim, jak dopravit do DAOcka Connection jinak, nez pres parametr metody. Takhle totiz muzu snadno zaridit, aby mi kazdy jeden request probehl v jedne transakci.

Takhle vypadá moje DI:

Kód: [Vybrat]

@Data
public class App {

    DatasourcePool datasourcePool;
    DataService dataService;
    LoginService loginService;
    RestApi restApi;
    TimelineDao timelineDao;


    public App() throws Exception {
        initProperties();

        datasourcePool = new DatasourcePool(
                "org.postgresql.Driver",
                System.getProperty("jdbc.connection"),
                System.getProperty("jdbc.user"),
                System.getProperty("jdbc.password")
        );
        timelineDao = new TimelineDao();
        dataService = new DataService(timelineDao);
        loginService = new LoginService();
        restApi = new RestApi(dataService, loginService, datasourcePool);
    }


Start na Tomcatovi je za 700ms.

Vypadá to hezky a na triviální úkoly typu select z jedné tabulky to taky tak používám.

Akorát, že se to celé neúměrně zesložití, jakmile začneme entity skládat (kde entita obsahuje kolekci jiných entit) a začneme ty entity ukládat do databáze, opětovně načítat, zjišťovat, zda se entita změnila, ověřovat kardinalitu... Skončíte na vlastním malém, ale nedokonalém ORM. To už je lepší použít něco hotového.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 14:11:16
To si nemyslím, že je problém, mám pro to úplně jasné řešení.

Kolikrát potřebujete mít 1:1 vztah Objekt-Tabulka? V naprosto zanedbatelném počtu přípádů. Vždy používáte složené dotazy, které jsou v podstatě kočkopes. Výstupem těch dotazů je ResultSet a k němu odpovídající ResultSetModel. Ten model nepředstavuje žádnou tabulku, představuje výstup z SQL dotazu, k němu je vztažen, a obsahuje mix informací z různých tabulek.

Ještě jednou, když máte trochu složitější databázi, tak vaše Objekty jsou SQL-orientované a né Tabulkově-orientované. Samostatné tabulky vás až tak nezajímají.

Tady mě právě sere ten Hibernate, já nikdy nejsem zvědavý na načítání celých tabulek, chci mít raději SQL-orientovaný ResultSetModel. Navíc tím dostanou krásnou svobodu čistého SQL.

Takže u Selectů je to jansé, tam mi přijde že jasně vede přístup přes JDBC.


Co se týče insertování nových záznamů, taaak....... tam opět moc nevidím problém, proč si myslíš, že se to zesložití? Vždyť ty nepotřebuješ komponovat Model třídy jako u Hibernate, to přece vůbec není nutné. Vždy sám v kódu víš, jestli k nově vkládanému řádku v tabulce A chceš přidat FID z již existujícího řádku v B, nebo chceš přidat i nový řádek do B a jeho id použít v A.

Taky co se týče updatu, tak tam taky snad nikdy nepořebuješ super-univerzální možnost updatovat kdykoliv cokoliv tak jak to umí Hibernate, v praxi vždycky potřebuješ z hlediska business logiky updatovat jen pár sloupečků v tabulce, na to si case-to-case uděláš nevou metodu do Daočka.

Problém je, že ty chceš, asi ze zvyku, nutně dělat ORM mapování, vč. reálných vazeb mezi Modely, tak jak to má hibernate. A TO JE PRÁVĚ to, co způsobuje ty problémy, u kterých skončíš tak, že hibernate použiješ rovnou. Ale proč to kompletní ORM chceš dělat, co ti to přinese? To přece vůbec není nutné, neumím si představit nějakou podstatnou výhodu.

Mě přijde SQL svět mnohem přehlednější a jasnější, a když dlám aplikaci, tak přece nad ním nechci dělat tlustou nadstavbu. Vždyť SQL to je asi ta nejsolidnější technologie co tu je, spolu třeba s REGEXem. Proč bych nad tím chtěl dělat nějakou tlustou nadstavbu je jedno v čem.

Mě přijde výhoda Hibernata-like frameworku, když děláš v nějaké totální žumpě s pomalým intranetem, kde přístup do soukromé databáze tvé komponenty je na s vysokou latencí a ty si tu svou databázi nemůžeš dát na stejný stroj kde ti ta tvá komponenta běží, ikdyž ji vlastně ta komponenta vlastní. To jsou ty typické Oracle sračky, kde je jedna obří databáze a ty v ní máš svého Usera. V ten moment ti nezbývá než si tu databázi kvůli latencím cachovat, protože by to jinak bylo pomalé jako prase. A tady může třeba ten Hibernate pomoct.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 17:35:41
Jo a ještě taková jedna věc, když jsem nepoužil Spring, integrační test se mi spustí ve vteřině:

Kód: [Vybrat]

@RunWith(JUnit4.class)
public class AppIT {

    App app;

    @Before
    public void init() throws Exception {
        app = new App();
    }

    @Test
    public void daoTest() throws SQLException, InterruptedException, InstantiationException, IllegalAccessException {
        KeywordDao kw = app.getKeywordDao();
        DatasourcePool dp = app.getDatasourcePool();

        List<FetchNewDataRS> fetchNewDataRS = kw.fetchNewDataRS(dp.getConnection());

        fetchNewDataRS.stream().forEach(System.out::println);

    }
}


Naprosto neskutečné, mám z toho radost :-) Když si vzpomenu, jaký to je porod pouštět integrační test se Springem, než se to načte atp.

Mám tady kopii té aplikace ve Springu a tam to startuje dobrých 8 vteřin, tragédie. Při spuščtěné aplikaci to jde alespoň díky Devtools, které však občas blbosu, jen za 2.5 vteřiny, ale to jaksi nejde v případě integračních testů.
A kdyby jenom to, ještě navíc mi to tam teď nahodile hází exception ohledně jakésik Hibernatí třídy a tu exception to jednou při startu vyhodí a jednou ne, takže je to nahodilé. Sranda docela.

Fuck off Spring.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 17:39:21
všimněte si v tom junit testu, že já v podstatě vytvořím instanci celé své aplikace App, která slouží zároveň jako DI kontext, a ta se prostě vytvoří okamžitě díky tomu, že nepoužívám reflexi a můj Datapool vytváří connections líně.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 28. 07. 2018, 18:21:51
To si nemyslím, že je problém, mám pro to úplně jasné řešení.

Kolikrát potřebujete mít 1:1 vztah Objekt-Tabulka? V naprosto zanedbatelném počtu přípádů. Vždy používáte složené dotazy, které jsou v podstatě kočkopes. Výstupem těch dotazů je ResultSet a k němu odpovídající ResultSetModel. Ten model nepředstavuje žádnou tabulku, představuje výstup z SQL dotazu, k němu je vztažen, a obsahuje mix informací z různých tabulek.

Ještě jednou, když máte trochu složitější databázi, tak vaše Objekty jsou SQL-orientované a né Tabulkově-orientované. Samostatné tabulky vás až tak nezajímají.

Tady mě právě sere ten Hibernate, já nikdy nejsem zvědavý na načítání celých tabulek, chci mít raději SQL-orientovaný ResultSetModel. Navíc tím dostanou krásnou svobodu čistého SQL.

Takže u Selectů je to jansé, tam mi přijde že jasně vede přístup přes JDBC.


Co se týče insertování nových záznamů, taaak....... tam opět moc nevidím problém, proč si myslíš, že se to zesložití? Vždyť ty nepotřebuješ komponovat Model třídy jako u Hibernate, to přece vůbec není nutné. Vždy sám v kódu víš, jestli k nově vkládanému řádku v tabulce A chceš přidat FID z již existujícího řádku v B, nebo chceš přidat i nový řádek do B a jeho id použít v A.

Taky co se týče updatu, tak tam taky snad nikdy nepořebuješ super-univerzální možnost updatovat kdykoliv cokoliv tak jak to umí Hibernate, v praxi vždycky potřebuješ z hlediska business logiky updatovat jen pár sloupečků v tabulce, na to si case-to-case uděláš nevou metodu do Daočka.

Problém je, že ty chceš, asi ze zvyku, nutně dělat ORM mapování, vč. reálných vazeb mezi Modely, tak jak to má hibernate. A TO JE PRÁVĚ to, co způsobuje ty problémy, u kterých skončíš tak, že hibernate použiješ rovnou. Ale proč to kompletní ORM chceš dělat, co ti to přinese? To přece vůbec není nutné, neumím si představit nějakou podstatnou výhodu.

Mě přijde SQL svět mnohem přehlednější a jasnější, a když dlám aplikaci, tak přece nad ním nechci dělat tlustou nadstavbu. Vždyť SQL to je asi ta nejsolidnější technologie co tu je, spolu třeba s REGEXem. Proč bych nad tím chtěl dělat nějakou tlustou nadstavbu je jedno v čem.

Mě přijde výhoda Hibernata-like frameworku, když děláš v nějaké totální žumpě s pomalým intranetem, kde přístup do soukromé databáze tvé komponenty je na s vysokou latencí a ty si tu svou databázi nemůžeš dát na stejný stroj kde ti ta tvá komponenta běží, ikdyž ji vlastně ta komponenta vlastní. To jsou ty typické Oracle sračky, kde je jedna obří databáze a ty v ní máš svého Usera. V ten moment ti nezbývá než si tu databázi kvůli latencím cachovat, protože by to jinak bylo pomalé jako prase. A tady může třeba ten Hibernate pomoct.

Pokud tomu dobře rozumím, složitosti skládání entit se vyhnete tím, že používáte anonymní ResultSetModel. A ostatním  problémům se vyhnete tím, že použijete jiný programátorský styl. Pro nějaké mikroprojekty to asi není problém, ale jinak se tím zbavujete jedné z možnosti jak dekomponovat aplikační doménu (problém, který má aplikace řešit). To je obecně spíš krok zpět. To už mi přijde lepší se objektově-relační impedanci (problému mapování objektů na sql) vyhnout použitím nějaké nativní objektové databáze.
Název: Re:Alternativa k Hibernate
Přispěvatel: peter 28. 07. 2018, 18:32:42
Tiez sa priklanam vynechat ORM. Zdoraznil by som ale pristup k databaze cez Declarative interface (napr  v jdbi).
V principe si spravis cisty interface, a ten potom pomocou sql dotazov implementujes. napr:

public interface ZmluvyDao{
 List<Zmluva> zoznamZmluv(String customerId);
 Zmluva zmluvaPodlaId(String cisloZmluvy);
 long vytvorZmluvu(Zmluva);
}

potom uz len pises sql dotazy k jednotlivym metodam
ZmluvyDao.zoznamZmluv:
sleect * from zmluvy where customerId=:customerId order by cisloZmluvy;
atd.

Ak sa dobre pozries na interface, pripomina API k nejakemu inemu systemu, ako by si databazu volal cez pripravene REST rozhranie. Takto vies aplikaciu oddelit od problematiky databazy. Proste si napises API ake potrebujes a potom si ho implementujes (napises sql ktore ho zrealizuju v db).

taketo rozdelenie vies potom vyuzit vo viacerych smeroch:

1. sql je netypovy jazyk bez moznosti validacie pri kompilovani aplikacie. Preto je absolutne nutne robit unit testy aby nahradili kompilacnu typovu validaciu. Pri takomto rozdeleni je to jednoduche. Vytvoris databazu (napr h2 v pamati),
spustis int scripty (napr. Flyway) a zacnes volat jednotilive methody interface. Takto si schopny otestovat celu databazu bez toho aby si sa prekusaval business logikou aplikacie ktora ju pouziva. Vies jednoducho skontrolovat ze si otestoval 100% volani db.

2. ak mas nad db vrstvou zlozitejsiu business logiku, vies specificke unit testy robit bez nutnosti vytvarania db, lebo db interface sa da lahko namokovat.

3. cirou nahodou si prave naplnil principy "hexagonal architecture"

4. neboj sa robit ine data objekty na citanie a ine na zapisovanie, ak to potrebujes. Vyhoda je ze vies priamo z databazy vytahovat DTO z public rozhrani aplikacie a nemusis ich premapovavat ako sa to bezne robi s hibernate. Ako pristupit k rozdielom pri zapise a cistani pozri napr na CQRS ktore to detailnejsie rozobera https://martinfowler.com/bliki/CQRS.html

Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 21:51:42
Tiez sa priklanam vynechat ORM. Zdoraznil by som ale pristup k databaze cez Declarative interface (napr  v jdbi).
V principe si spravis cisty interface, a ten potom pomocou sql dotazov implementujes. napr:

public interface ZmluvyDao{
 List<Zmluva> zoznamZmluv(String customerId);
 Zmluva zmluvaPodlaId(String cisloZmluvy);
 long vytvorZmluvu(Zmluva);
}

potom uz len pises sql dotazy k jednotlivym metodam
ZmluvyDao.zoznamZmluv:
sleect * from zmluvy where customerId=:customerId order by cisloZmluvy;
atd.

Ak sa dobre pozries na interface, pripomina API k nejakemu inemu systemu, ako by si databazu volal cez pripravene REST rozhranie. Takto vies aplikaciu oddelit od problematiky databazy. Proste si napises API ake potrebujes a potom si ho implementujes (napises sql ktore ho zrealizuju v db).

taketo rozdelenie vies potom vyuzit vo viacerych smeroch:

1. sql je netypovy jazyk bez moznosti validacie pri kompilovani aplikacie. Preto je absolutne nutne robit unit testy aby nahradili kompilacnu typovu validaciu. Pri takomto rozdeleni je to jednoduche. Vytvoris databazu (napr h2 v pamati),
spustis int scripty (napr. Flyway) a zacnes volat jednotilive methody interface. Takto si schopny otestovat celu databazu bez toho aby si sa prekusaval business logikou aplikacie ktora ju pouziva. Vies jednoducho skontrolovat ze si otestoval 100% volani db.

2. ak mas nad db vrstvou zlozitejsiu business logiku, vies specificke unit testy robit bez nutnosti vytvarania db, lebo db interface sa da lahko namokovat.

3. cirou nahodou si prave naplnil principy "hexagonal architecture"

4. neboj sa robit ine data objekty na citanie a ine na zapisovanie, ak to potrebujes. Vyhoda je ze vies priamo z databazy vytahovat DTO z public rozhrani aplikacie a nemusis ich premapovavat ako sa to bezne robi s hibernate. Ako pristupit k rozdielom pri zapise a cistani pozri napr na CQRS ktore to detailnejsie rozobera https://martinfowler.com/bliki/CQRS.html

Pointu interfacu jsem zati moc nepochytil, kde jsem je na projektu měl tak byly úplně na hovno, jenom takový maras přes který se musíš v kódu proklikávat. Přijde mi to zbytečné a byrokratické.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 21:53:27
Jak zminujes to Mockovani, tak interface se sice da namockovat, to jo, ale to stejne tak muzes udelat reflexi. Ja jak moc reflexi nemusim, tak na testovani to je jedno.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 28. 07. 2018, 22:13:10
Pointu interfacu jsem zati moc nepochytil, kde jsem je na projektu měl tak byly úplně na hovno, jenom takový maras přes který se musíš v kódu proklikávat. Přijde mi to zbytečné a byrokratické.

Pointa interfaců je ta, máš jeden interface a více možných implementací. Místo ArrayList používáš všude interface List. To rozhodně není zbytečné, protože to umožňuje pracovat s objektem, aniž bych znal jeho přesný typ. Spíš naopak, chtělo by to je ještě rozšířit, protože třeba jsou pořád možnosti interfaců tak trochu nedomrlé.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 22:38:43
Pointu interfacu jsem zati moc nepochytil, kde jsem je na projektu měl tak byly úplně na hovno, jenom takový maras přes který se musíš v kódu proklikávat. Přijde mi to zbytečné a byrokratické.

Pointa interfaců je ta, máš jeden interface a více možných implementací. Místo ArrayList používáš všude interface List. To rozhodně není zbytečné, protože to umožňuje pracovat s objektem, aniž bych znal jeho přesný typ. Spíš naopak, chtělo by to je ještě rozšířit, protože třeba jsou pořád možnosti interfaců tak trochu nedomrlé.

No tak tam je to jasné, ale dělat na každé DAO nebo Service Interface je prostě nanic. K čemu ti to je, nikdy nebudeš mít vícero implementací jedné beany. A pokud ano, tak tomu uděláš ten interface, ale to je minorita případů. Naco dávat automaticky ke každému DAO interface... Navíc předělat současnou třídu na interface můžeš vždy.
Název: Re:Alternativa k Hibernate
Přispěvatel: Peter 28. 07. 2018, 22:47:58
Pointa interface v tom DAO je ze nepises implementaciu. Tu spravi reflection z toho interface a sql suboru.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 23:32:37
Pointa interface v tom DAO je ze nepises implementaciu. Tu spravi reflection z toho interface a sql suboru.

Jo já už vím co myslíš, to umí MyBatis. Jenže zase je tam zatím nějaký magic přes reflexi co ti musí nastartovat když spouštíš aplikaci. To prostě nechci, nad tím je postavený celý Spring. A na ten jsem se vykaslal protoze je to magic a má bugy. Jak tam jednou začněš dělat takový magic, tak v jakém bodě skončíš? (U SPring Data JPA, otřesná věc)
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 28. 07. 2018, 23:44:48
Takhle vypadá můj Rest, není to žádná sláva, ale když to setřídím podle abecedy a odsadím, dá se v tom vyznat.

Kód: [Vybrat]
            if ((p = matches(req,            "/keyword",         "GET")) != null) {
                rslt = dataService.findAllKeywords();
            }

            else if ((p = matches(req,      "/keyword/{id}",    "GET")) != null) {
                rslt = dataService.findKeyword(p.get(0));
            }

            else if ((p = matches(req,      "/logout",          "GET")) != null) {
                boolean success = loginService.logout(req);
                rslt = "Logout was " + (success ? "successful" : "unsuccessful.");
            }
           
            else if ((p = matches(req,      "/login/{user}/{password}",       "GET")) != null) {
                rslt = loginService.login(req, p.get(0), p.get(1));
            }

            else if ((p = matches(req,      "/secretsection",   "GET")) != null && loginService.isLoged(req)) {
                rslt = "You are in the secret section!";
            }

            if ((p = matches(req,           "/timeline",        "GET")) != null) {
                rslt = dataService.findAllTimelines(connStatements);
            }

            else if ((p = matches(req,      "/info",            "GET")) != null ) {
                rslt = getRestMap();
            }

            else {
                pw.println("This URI is not connected to any service: '" + req.getPathInfo() + "' method: '" +
                req.getMethod() + "'");
            }

Název: Re:Alternativa k Hibernate
Přispěvatel: Filip Jirsák 29. 07. 2018, 08:53:28
A na ten jsem se vykaslal protoze je to magic a má bugy.
Jak jste se vedle ptal na ty výborné programátory, tak výborný programátor, pokud mu nějaká aplikace nebo knihovna připadá „magic“, tak se podívá do zdrojáků, pochopí, jak to funguje, a magie je pryč. A pokud narazí na chybu, tak ji opraví a pošle patch.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 29. 07. 2018, 09:46:51
A na ten jsem se vykaslal protoze je to magic a má bugy.
Jak jste se vedle ptal na ty výborné programátory, tak výborný programátor, pokud mu nějaká aplikace nebo knihovna připadá „magic“, tak se podívá do zdrojáků, pochopí, jak to funguje, a magie je pryč. A pokud narazí na chybu, tak ji opraví a pošle patch.

Jako že se budu proklikávat přes všechny ty Interfacy a Abstrakce ve Springu??????????????!!!!!!!!!!!!! Tak to vám upřímně říkám, že tak "dobrý programátor" nebudu nikdy, na to prostě nejsem zvědavý. Tam se nikdy neproklikáte jen k nějakému kusu kódu jako ve standardní JDK když se mrknu do HashMapy. U takových knihoven jako je Spring se nikdy nepodíváte na kousek něčeho co zrovna potřebujete!

Asi prostě hloupý programátor jako já potřebuje buďto jednoduchý framework, a nebo framework který prostě funguje na 100%. (A to je musí být opět jednoduchý framework, protože ty složite věci více méně nefungují vždy).

Moje ideální představa o opensource frameworku vypadá takhle:

Je to seznam výborných samostatných knihoven, které splňují "Dělá to jednu věc, a tu to dělá dobře". K tomu frameworku je trocha example příkladů, které tvoří různá usecase. A je k tomu manuál, který nepopisuje složitě udělaný framework, ale popisuje, jak pomocí těch kostiček poskládat aplikaci. Něco jako je Arch linux. Tohle je pro mě ideální framework - protože to vlastně není úplně framework ve smyslu nějakého blackboxu, ale je to knowhow + knihovny a postupy.

A ten manual je udělaný ve smyslu rostoucí aplikace: dělám minimální konfiguraci toho, co vlastně potřebuju, a když chci něco přidat, dočtu se tam jak bych to měl přidat. Takže ne jako Spring, kde když chci Rest, Thymeleaf a login do své aplikace, tak mi 7 vteřin startuje půlka prasete.
Název: Re:Alternativa k Hibernate
Přispěvatel: Filip Jirsák 29. 07. 2018, 10:13:16
Jako že se budu proklikávat přes všechny ty Interfacy a Abstrakce ve Springu?
Jaký je rozdíl mezi rozhraním a abstraktní třídou a k čemu slouží se ptáme na pohovorech kandidátů na juniorskou pozici.

Mimochodem, kdybyste se někdy opravdu podíval na implementaci java.util.HashMap, nebo alespoň na její rozhraní, zjistil byste, že dědí od abstraktní třídy java.util.AbstractMap a implementuje rozhraní java.util.Map.

Tam se nikdy neproklikáte jen k nějakému kusu kódu jako ve standardní JDK když se mrknu do HashMapy. U takových knihoven jako je Spring se nikdy nepodíváte na kousek něčeho co zrovna potřebujete!
Mluvte za sebe. Věřím vám, že vy se na to nikdy nepodíváte. Já ano.

Asi prostě hloupý programátor jako já potřebuje buďto jednoduchý framework, a nebo framework který prostě funguje na 100%. (A to je musí být opět jednoduchý framework, protože ty složite věci více méně nefungují vždy).

Moje ideální představa o opensource frameworku vypadá takhle
Hloupý programátor nikdy nevymyslí dobrý framework. Takže byste měl hlavně zapomenout na vaše naivní představy a naučit se aspoň základně používat něco, co vymysleli lidé chytřejší než vy.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 29. 07. 2018, 10:39:46
Hloupý programátor nikdy nevymyslí dobrý framework. Takže byste měl hlavně zapomenout na vaše naivní představy a naučit se aspoň základně používat něco, co vymysleli lidé chytřejší než vy.

Ano, asi bych měl, asi bych měl prostě sklopit hlavu a zabít si po sobě několik víkendů jenom proto, že ve Springu je bug! Asi bych měl sklopil hlavu, říct si že jsem čurák a nechat si vysát všechen volný čas touhletou hydrou, které se inkrementuje verze z 2.0.2 na 2.0.3 a rázem je všechno jinak!

Vy prostě ústavičně děláte z lidí nějaké pitomce. To by dozadeke bylo, abyste uznal, že nějaký soft prostě stojí za hovno. U vás zřejmě soft je vždy ok a problém je vždy mezi židlí a klávesnicí. A takoví lidi, co se nasrali a vymysleli třeba Go nebo Python, protože viděli, jak je všechno nebetyčně přeinženýrované, tak to jsou u vás asi pitomci.

Tuhle se mnou třeba vyjebal v minulé práci Spring a AOP. Jednou za čas, když je zdupaný testovací enviroment neumožňující profilovat JVM,  člověk potřebuje zasrané AOP, aby si na balíčku mohl logovat časy spuštění metod. Celou dobu to AOP má a člověk tu jebku prostě nevyužije, protože normálně je úplně na hovno, ale ve zkurveném žumpen projektu nastane jednoho dne taková situaca. A výsledek? Ta jebka prostě nefunguje, protože ve Springu verze 3.5 je bug, že když aop narazaí na Vararg v metodě, tak to prostě vyhodí exception a sesype se to. Fuck off.

Lepší by bylo, kdyby tam žádné zkurvené AOP nebylo. To bych totiž nasázel do balíčku logování ručně do každé metody a měl bych to hotové dřív, než se dupat se zasraným Springem.

K čemu to je, že to má tolik featur, když to DPČ NEGUNGUJE POŘADNĚ!!! A to bych mohl pokračovat a pokračovat, kdy a jak se mnou ta jebka Spring vyjebala.

Teď v tom Spring Bootu udělali zase nějaký magic s embedded servlet kontejnerem, že jim to nastartuje za cca 7 vteřin. Náhodně mi tam při startu funguje a nefunguje jakásik Hibernatí závislost, prostě to vyhodí exception a čau. Při dalším startu to je zase ok. (obojí myslím kompletní restart, ne Devtools magic). Nevím čím to je. Možná Command Line Runnerem, že se někdy spustí dřív než se inicializovaly některé beany? Nebo možná je tam někde uvnitř v te jebce zase někde bug. Každopádně vím to, že to prostě nechci řešit, protože na to nemám čas. Vím, že bych na téhleté exception mohl klidně spálit 2 dny svého volného času.

Název: Re:Alternativa k Hibernate
Přispěvatel: Filip Jirsák 29. 07. 2018, 12:56:04
Vy prostě ústavičně děláte z lidí nějaké pitomce.
Nedělám. Děláte ho ze sebe vy sám, tím, co sem píšete.

U vás zřejmě soft je vždy ok a problém je vždy mezi židlí a klávesnicí.
Ale nevymlouvejte se. Já to netvrdím o všem a o všech, tvrdím to konkrétně o vás, na základě toho, co tady píšete.

K čemu to je, že to má tolik featur, když to DPČ NEGUNGUJE POŘADNĚ!!! A to bych mohl pokračovat a pokračovat, kdy a jak se mnou ta jebka Spring vyjebala.
Jasně, chyba je ve všem okolo, jenom vy jste dokonalý. Mimochodem, to jste narazil na další vlastnost výborných programátorů – nejprve hledají chybu u sebe a ve svém kódu, teprve pak u ostatních.

Teď v tom Spring Bootu udělali zase nějaký magic s embedded servlet kontejnerem, že jim to nastartuje za cca 7 vteřin.
Ne jim, ale vám. Ostatním to funguje správně.
Název: Re:Alternativa k Hibernate
Přispěvatel: Youda 29. 07. 2018, 17:04:28
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?

Samy o sobě nijak, ale obvykle se používají v souvislosti s tím, že máš v DB víc uživatelů, a ten, pod kterým tam chodí aplikace má jen omezená práva, není vlastníkem objektů a nemůže dělat INSERT, UPDATE atd. a může jen volat ty procedury + SELECTy na určitých tabulkách.

Co se týče transakcí, ty bych do procedur většinou nedával a řešil je vně – tak, aby si transakci mohl řídit ten, kdo to volá a nebylo to zadrátované v proceduře. Výjimkou je logování, které se dělá v autonomní transakci (zalogováno chci mít vše, i když se na konci udělá ROLLBACK a/nebo vyletí nějaká výjimka) a některé speciální případy.

Transakci v procedurach jsem mel namysli, ze PLSQL proceduru pouzivam jako uzavrenou transakcni jednotku, atomickou operaci, ktera bud komplet dobehne nebo rollbackne
V Java kodu mam pak pouze atomicke selecty (zabalene v lidsky citelnych views) a executy, vubec neresim transakce na hibernate urovni.

Pro slozitejsi veci je to mozna malo, ale pro vetsinu beznych zalezitosti tento pristup postacuje, reseni je krasne citelne, rychle a je odolne vuci chybam.
Defacto se snazim z celeho Hibernatu pouzivat jenom connection pool a bean mapper.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 29. 07. 2018, 17:37:57
Vy prostě ústavičně děláte z lidí nějaké pitomce.
Nedělám. Děláte ho ze sebe vy sám, tím, co sem píšete.

U vás zřejmě soft je vždy ok a problém je vždy mezi židlí a klávesnicí.
Ale nevymlouvejte se. Já to netvrdím o všem a o všech, tvrdím to konkrétně o vás, na základě toho, co tady píšete.

K čemu to je, že to má tolik featur, když to DPČ NEGUNGUJE POŘADNĚ!!! A to bych mohl pokračovat a pokračovat, kdy a jak se mnou ta jebka Spring vyjebala.
Jasně, chyba je ve všem okolo, jenom vy jste dokonalý. Mimochodem, to jste narazil na další vlastnost výborných programátorů – nejprve hledají chybu u sebe a ve svém kódu, teprve pak u ostatních.

Teď v tom Spring Bootu udělali zase nějaký magic s embedded servlet kontejnerem, že jim to nastartuje za cca 7 vteřin.
Ne jim, ale vám. Ostatním to funguje správně.

No ale on má částečně pravdu, overhead při práci s frameworkem může být docela velký, pokud ho člověk opravdu dobře neovládá. Chytrý a zkušený programátor ho sice lépe zvládne, ale to ještě neznamená, že je to ideální situace. Kdo z nás nestrávil x hodin kvůli nějaké chybě v nějaké knihovně?

Samotný Spring vznikl jako reakce na složitost EJB a chtěl být právě jednoduchý a přímočarý. Skutečnost, že už taky nabobtnal, jasně ukazuje, že zachovat jednoduchost u velkých projektů je prakticky nemožné. Což je ale zároveň argument, který by měl hlavu původního tazatele trochu ochladit. Protože na druhou stranu každý už asi zažil, že začal používat nadšeně nějaký odlehčený framework, ale po čase narazil na jeho omezení a zjistil, že musí spoustu věcí doprogramovat anebo použít něco masivnějšího.

Prostě hlavní dovednost pro chytrého i průměrného programátora je najít nástroj přiměřený danému úkolu. V daném případě by autor buď neměl použít Boot anebo by měl věnovat úsilí k jeho ovládnutí.
Název: Re:Alternativa k Hibernate
Přispěvatel: Filip Jirsák 29. 07. 2018, 18:17:05
No ale on má částečně pravdu, overhead při práci s frameworkem může být docela velký, pokud ho člověk opravdu dobře neovládá.
To je ovšem něco jiného, než co tvrdí anonym. Navíc on tady popisuje příklady, které mohl opsat z dokumentace, kdyby ji ráčil otevřít.

Samotný Spring vznikl jako reakce na složitost EJB a chtěl být právě jednoduchý a přímočarý. Skutečnost, že už taky nabobtnal, jasně ukazuje, že zachovat jednoduchost u velkých projektů je prakticky nemožné.
Spring sice nabobtnal, ale zároveň se používá snáz, než dřív. Což má ty negativní důsledky, že se ho snaží použít i lidé jako anonym.

Jinak Spring není žádná krása, když se podíváte dovnitř, je vidět, jaký je to slepenec všeho možného, co řešilo konkrétní problém, a teprve nad tím je to relativně slušné API. I když základní knihovna Javy na tom vlastně není o mnoho lépe. Ale jak v JDK tak ve Springu se v poslední době věnuje docela úsilí pročištění.

Prostě hlavní dovednost pro chytrého i průměrného programátora je najít nástroj přiměřený danému úkolu. V daném případě by autor buď neměl použít Boot anebo by měl věnovat úsilí k jeho ovládnutí.
Tady ani nebylo potřeba věnovat úsilí ovládnutí Springu, stačilo vybrat si ten správný z mnoha příkladů a upravit ho. Anonym se tu ptal na úplně základní věci, které jsou popsané krok za krokem v dokumentaci a jsou na to příklady.
Název: Re:Alternativa k Hibernate
Přispěvatel: BoneFlute 29. 07. 2018, 19:52:59
No ale on má částečně pravdu, overhead při práci s frameworkem může být docela velký, pokud ho člověk opravdu dobře neovládá. Chytrý a zkušený programátor ho sice lépe zvládne, ale to ještě neznamená, že je to ideální situace. Kdo z nás nestrávil x hodin kvůli nějaké chybě v nějaké knihovně?

Je docela zajímavý rozdíl mezi frameworkem a knihovnou. Framework vynucuje určitý styl, špatně se zaměňuje. Knihovna obvykle naopak; používat si ji můžete jak chcete, často jste omezeni prostředky jazyka, můžete ji snáz zaměnit, nebo použávat vícero zároveň. Což má pak samozřejmě vliv na důsledky bugu v takové knihovně či frameworku.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 04. 08. 2018, 18:05:03
No takže skusil jsem si JAX-RS přes Jersey, stáhnul jsem si obyč hello world appku:

https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey.samples&a=helloworld-webapp&v=1.19.1&c=project&e=zip

a redeploy na Tomcat je za 3-3.5 vteřiny. V porovnání moje appka je redeploynutá za 0.75 vteřiny.

Tohleto to je opravdu do nebe volající a neúnosné. 3.5 vteřiny to je pro počítač věčnost. Co to tam tyvole tak dlouho dělá? Vypočítává to nekonečno vakua? Chápu, že reflexe je pomalá, ale nemůže být přece až takhle pomalá, navíc je tam jen jediný controller s jedinou metodou. Tohleto to je prostě totální shit.

Vidím že pověsti o Javě jsou někdy bohužel pravdivé.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 04. 08. 2018, 20:10:39
No takže skusil jsem si JAX-RS přes Jersey, stáhnul jsem si obyč hello world appku:

https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey.samples&a=helloworld-webapp&v=1.19.1&c=project&e=zip

a redeploy na Tomcat je za 3-3.5 vteřiny. V porovnání moje appka je redeploynutá za 0.75 vteřiny.

Tohleto to je opravdu do nebe volající a neúnosné. 3.5 vteřiny to je pro počítač věčnost. Co to tam tyvole tak dlouho dělá? Vypočítává to nekonečno vakua? Chápu, že reflexe je pomalá, ale nemůže být přece až takhle pomalá, navíc je tam jen jediný controller s jedinou metodou. Tohleto to je prostě totální shit.

Vidím že pověsti o Javě jsou někdy bohužel pravdivé.

Tohle už je čistý trolling. Oboje je java - a pokud vám vadí 3s deploy tak použijte něco jiného, ne? Ať už v javě nebo něčem jiném. Stěžovací témata patří někam do volné diskuze, ne na technické fórum.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 04. 08. 2018, 20:50:54
Kurvadrát. Za 3.5 vteřiny dpč nabootuje celý Linux! Za 10 vteřin mi do plochy nabootují Windows 10! Ale Spring posraný Boot mi startuje v základu jen s Jersey 4.5 vteřiny!!! Co je to za bordel dpč. A teď jsem zjistil, že ikdyž udělám projekt jen s tou posranou Jersey, tak deploy na Tomcat zabere 3.5 vteřiny. No co to dpč. má být tohleto.

Ale genius Nemecek mi pise, ze si nemam stezovat a mam pouzit neco jineho. A co asi tak jineho nez JAX-RS chceš dpč v Javě používat???

Fakt lidi se prostě spokojií ss kdejakým shitem a ještě tě budou přesvědčovat, jak je to super.
Název: Re:Alternativa k Hibernate
Přispěvatel: David 04. 08. 2018, 21:17:54
Vyjadřujete se jako idiot. Jinak Spring Boot aplikace s databázi a webserverem mi startuje 10-20 vteřin a přijde mi to v pořádku ;) Dělat se s tím nic nedá, ale to nevadí, protože jak často asi tu aplikaci spouštíte ;)
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 04. 08. 2018, 21:37:43
Vyjadřujete se jako idiot. Jinak Spring Boot aplikace s databázi a webserverem mi startuje 10-20 vteřin a přijde mi to v pořádku ;) Dělat se s tím nic nedá, ale to nevadí, protože jak často asi tu aplikaci spouštíte ;)

Já se tak vyjadřuju a ty jím zřejmě jsi, jestli ti přijde v pořádku, aby ti pár sraček kódu startovalo 10-20 vteřin. Když pouštíš integrační test, tak to ti taky přijde v pořádku čekat, než ti ten sráč nastartuje? Jó aha, ty vlastně IT něděláš, ty si to totiž testuješ unit testy. Jo aha, jenže ty shitty zabordelené unit testy používat musíš, protože ti to jinak startuje 10-20 vteřin. Typický Javista.

Nejlehčí věc co se dá sehnat je Spark framewrok s jetty. Jenže i ten sráč ebedded jetty startuje 2.5 vteřiny.

Teď jsem si schválně zkusil Golang projekt s restem. Jak dlouho to startuje? Do 50ms to nastartuje a vrátí do prohlížeče hello world! Prostě okamžite! Takhle to má vypadat, konečně se cítím jako člověk.

PS: už se těším až ta Java chcípne, protože tohleto je takový bordel, že si to ani nic jiného nezaslouží. Do te doby ještě posedím v korporátě.
Název: Re:Alternativa k Hibernate
Přispěvatel: Trollopata 04. 08. 2018, 21:59:46
Je docela zajímavý rozdíl mezi frameworkem a knihovnou. Framework vynucuje určitý styl, špatně se zaměňuje. Knihovna obvykle naopak; používat si ji můžete jak chcete, často jste omezeni prostředky jazyka, můžete ji snáz zaměnit, nebo použávat vícero zároveň. Což má pak samozřejmě vliv na důsledky bugu v takové knihovně či frameworku.
To také není úplně přesné. Framework také nemusí být nutně invazivní a nemusí nutit do konkrétního stylu, případně může poskytnout více možností, jak něčeho docílit (např. Spring – mohu použít třeba Spring Core k dependency injection, přičemž poskytuje více možností, jak definovat a injektovat beany, pro web už ale nemusím využít Spring MVC, když nechci, a místo toho třeba Vaadin).

Hlavní rozdíl je v tom, že knihovna zpravidla implementuje nějakou úzce specifickou logiku (knihovna pro matematické výpočty, pro přístup k DB, generování obrázků atd.), takže ve vlastní aplikaci nemusím vynalézat kolo. Framework zase poskytuje prostředky pro vytvoření "rámce" (kostry) aplikace. V každé aplikaci pak není třeba znovu psát tentýž "boilerplate" kód a v ideálním případě je možné se věnovat jen business kódu. Framework samozřejmě může poskytovat i různé integrované knihovny.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 04. 08. 2018, 22:50:26
Vyjadřujete se jako idiot. Jinak Spring Boot aplikace s databázi a webserverem mi startuje 10-20 vteřin a přijde mi to v pořádku ;) Dělat se s tím nic nedá, ale to nevadí, protože jak často asi tu aplikaci spouštíte ;)

Já se tak vyjadřuju a ty jím zřejmě jsi, jestli ti přijde v pořádku, aby ti pár sraček kódu startovalo 10-20 vteřin. Když pouštíš integrační test, tak to ti taky přijde v pořádku čekat, než ti ten sráč nastartuje? Jó aha, ty vlastně IT něděláš, ty si to totiž testuješ unit testy. Jo aha, jenže ty shitty zabordelené unit testy používat musíš, protože ti to jinak startuje 10-20 vteřin. Typický Javista.

Nejlehčí věc co se dá sehnat je Spark framewrok s jetty. Jenže i ten sráč ebedded jetty startuje 2.5 vteřiny.

Teď jsem si schválně zkusil Golang projekt s restem. Jak dlouho to startuje? Do 50ms to nastartuje a vrátí do prohlížeče hello world! Prostě okamžite! Takhle to má vypadat, konečně se cítím jako člověk.

PS: už se těším až ta Java chcípne, protože tohleto je takový bordel, že si to ani nic jiného nezaslouží. Do te doby ještě posedím v korporátě.

Pokud potřebujete start do 50ms tak použijte ten Golang a máte po starosti, ne? Jinak mě startuje Spark s embedded Jetty 300ms. Ale podle mě skutečně trollíte a bavíte se tím.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 04. 08. 2018, 22:56:25
Zápis do deníčku:

Milý deničku. Po předchozích nezdarech a rozčarování z pomalých startů java aplikací jsem ještě jednou, naposledy, zkusil dát Javě šanci, a změřit čas, za který se rozjede Vert.x, který má být v současnosti snad jeden z nejrychlejších http serverů:

Kód: [Vybrat]
public class HelloWorldEmbedded {

  public static void main(String[] args) {
    long timer = System.currentTimeMillis();
    // Create an HTTP server which simply returns "Hello World!" to each request.
    Vertx.vertx().createHttpServer().requestHandler(req -> req.response().end("Hello World!")).listen(8080);

    timer = System.currentTimeMillis() - timer;
    System.out.println(timer);
  }

}

Milý Deníčku. Ten sráč startoval celých 2400ms:

Kód: [Vybrat]
2391

Píšu výsledek tohoto benchmarku tobě, Deníčku, protože ty nejsi takový idiot abys mi na to řekl, že tento způsob benchmarkování není přesný a nemá vypovídající hodnotu.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 04. 08. 2018, 22:58:57
Vyjadřujete se jako idiot. Jinak Spring Boot aplikace s databázi a webserverem mi startuje 10-20 vteřin a přijde mi to v pořádku ;) Dělat se s tím nic nedá, ale to nevadí, protože jak často asi tu aplikaci spouštíte ;)

Já se tak vyjadřuju a ty jím zřejmě jsi, jestli ti přijde v pořádku, aby ti pár sraček kódu startovalo 10-20 vteřin. Když pouštíš integrační test, tak to ti taky přijde v pořádku čekat, než ti ten sráč nastartuje? Jó aha, ty vlastně IT něděláš, ty si to totiž testuješ unit testy. Jo aha, jenže ty shitty zabordelené unit testy používat musíš, protože ti to jinak startuje 10-20 vteřin. Typický Javista.

Nejlehčí věc co se dá sehnat je Spark framewrok s jetty. Jenže i ten sráč ebedded jetty startuje 2.5 vteřiny.

Teď jsem si schválně zkusil Golang projekt s restem. Jak dlouho to startuje? Do 50ms to nastartuje a vrátí do prohlížeče hello world! Prostě okamžite! Takhle to má vypadat, konečně se cítím jako člověk.

PS: už se těším až ta Java chcípne, protože tohleto je takový bordel, že si to ani nic jiného nezaslouží. Do te doby ještě posedím v korporátě.

Pokud potřebujete start do 50ms tak použijte ten Golang a máte po starosti, ne? Jinak mě startuje Spark s embedded Jetty 300ms. Ale podle mě skutečně trollíte a bavíte se tím.

Děláš si zadek???? Jak jenom 300ms, mě to startuje 2.5 vteřiny!!! Co máš za stroj? Já mám notebookové i7 dvoujádro, ssd a 16gb ram.

Ty vole jestli zjistím, že mi to dělá antivir něbo nějaký podobný shit, tak asi budu muset obrátit svou zlobu zcela jinam.
Název: Re:Alternativa k Hibernate
Přispěvatel: none_ 04. 08. 2018, 23:55:26
Predppkladam, ze jste troll, ale je miziva šance, ze si tohle precte nekdy nekdo, kdo to bude opravdu resit.

Kazdy framework ma nejaky overhead. Ukazte mi jazyk, ve kterem startuje aplikace stejne rychle s frameworkem jako s jednim servletem. Zadny takovy neexistuje. Framework neslibuje rychly start, ale mnozinu nastroju, ktere zlepsi vasi celkovou produktivitu, prehlednost kodu, vyresi klicove oblasti.

Pokud delate na projektu, kde tyto vyhody nevyuzijete, asi nemate dostatecne velky projekt. To nevadi. Pouzijte si neco jineho. Nebo si to klidne napraste jako 20 IFu za sebou.

Spring byl primarne navrzen jako nahrada za JavaEE. Takze se pouziva na vyvoj aplikaci, kde vas trápí jine problemy nez to, jestli server nastartuje za 0s, 2s nebo 2 min.

Podobny pribeh je Hibernate. Ocividne ho neznate, nechapete a neumite pouzivat. To nevadi, nemusite ho pouzivat. Klidne si pouzivejte JDBC. Co na tom, ze ten vas kod na namapovani jednoho objektu prochazi resultset 2x a jeste vam to kazda zmena v DB rozbije (protoze poradi sloupcu).

Hodne stesti a preju mnoho dlouhych noci stravenych hledanim chyb v tom vasem projektu (hlavne pokud na tom nekdy bude delat vic nez jeden clovek).
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 05. 08. 2018, 01:00:43
Vyjadřujete se jako idiot. Jinak Spring Boot aplikace s databázi a webserverem mi startuje 10-20 vteřin a přijde mi to v pořádku ;) Dělat se s tím nic nedá, ale to nevadí, protože jak často asi tu aplikaci spouštíte ;)

Já se tak vyjadřuju a ty jím zřejmě jsi, jestli ti přijde v pořádku, aby ti pár sraček kódu startovalo 10-20 vteřin. Když pouštíš integrační test, tak to ti taky přijde v pořádku čekat, než ti ten sráč nastartuje? Jó aha, ty vlastně IT něděláš, ty si to totiž testuješ unit testy. Jo aha, jenže ty shitty zabordelené unit testy používat musíš, protože ti to jinak startuje 10-20 vteřin. Typický Javista.

Nejlehčí věc co se dá sehnat je Spark framewrok s jetty. Jenže i ten sráč ebedded jetty startuje 2.5 vteřiny.

Teď jsem si schválně zkusil Golang projekt s restem. Jak dlouho to startuje? Do 50ms to nastartuje a vrátí do prohlížeče hello world! Prostě okamžite! Takhle to má vypadat, konečně se cítím jako člověk.

PS: už se těším až ta Java chcípne, protože tohleto je takový bordel, že si to ani nic jiného nezaslouží. Do te doby ještě posedím v korporátě.

Pokud potřebujete start do 50ms tak použijte ten Golang a máte po starosti, ne? Jinak mě startuje Spark s embedded Jetty 300ms. Ale podle mě skutečně trollíte a bavíte se tím.

Děláš si zadek???? Jak jenom 300ms, mě to startuje 2.5 vteřiny!!! Co máš za stroj? Já mám notebookové i7 dvoujádro, ssd a 16gb ram.

Ty vole jestli zjistím, že mi to dělá antivir něbo nějaký podobný shit, tak asi budu muset obrátit svou zlobu zcela jinam.

Mám i7-2860QM, 16GB RAM a SSD, testuju takhle:

Kód: [Vybrat]
import static spark.Spark.*;
public class Run {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");
    }
}

Kód: [Vybrat]
java -cp .:javax.servlet-api-4.0.1.jar:jetty-client-9.4.12.RC1.jar:jetty-http-9.4.12.RC1.jar:jetty-io-9.4.12.RC1.jar:jetty-security-9.4.12.RC1.jar:jetty-server-9.4.12.RC1.jar:jetty-servlet-9.4.12.RC1.jar:jetty-util-9.4.12.RC1.jar:jetty-webapp-9.4.12.RC1.jar:jetty-xml-9.4.12.RC1.jar:slf4j-api-1.7.25.jar:slf4j-jdk14-1.7.25.jar:slf4j-simple-1.7.25.jar:spark-core-2.7.2.jar:websocket-api-9.4.12.RC1.jar:websocket-client-9.4.12.RC1.jar:websocket-common-9.4.12.RC1.jar:websocket-server-9.4.12.RC1.jar:websocket-servlet-9.4.12.RC1.jar Run
(...)
INFO: == Spark has ignited ...
Srp 05, 2018 12:54:57 DOP. spark.embeddedserver.jetty.EmbeddedJettyServer ignite
(...)
Srp 05, 2018 12:54:57 DOP. org.eclipse.jetty.server.Server doStart
INFO: Started @345ms

Včetně kompilace toho Run.java to trvá cca 700ms.
Název: Re:Alternativa k Hibernate
Přispěvatel: andy 05. 08. 2018, 03:46:48
Znamy problem je resolve localhostu cez dns vo windows co sposobuje pomaly start serverovych apiek. Treba si pridat do hosts.
Tie procky sa v tych bankach stale pouzivaju a implementuju, nie je to ziadny archaizmus a pouzivaju sa z rovnakeho dovodu ako pouzivate v jave interfacy.
Co sa klasickeho springu tyka, je to moloch a křáp a nevidim dovod to dnes pouzit. Bolo to inovativne vo svojej dobe, ale motivacia pouzit to na novy projekt je nulova.
To s tym golangom je pravda. Je to rychle ako sracka a usporne aj pri zlozitejsej apke. Nestopoval som ako dlho startuju frameworky, ale ked som to skusal nasekal som tam zavislosti od vymyslu sveta a ziadne spomalenie sa nekonalo. Tam je to totiz staticky kompilovane, ma to vstavane performance testy a ta kultura je taka, ze kazdy tuninguje co to da.. Ale ten jazyk mi ako javistovi dost nevyhovuje.
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 05. 08. 2018, 10:25:23
No zkusil jsem ten Vert.x (jede to nad Netty) rozjet jak na "localhost", tak na "127.0.0.1" a žádný rozdíl se nedostavil. Používám Windows 7, zkoušel jsem porovnávat perfromance s Linuxem při startu aplikací, ale není to lepší o více než 10%. Nicméně mám takovou teorii, že Oracle začal těžit na mém JVM Bitcoiny.

Jenže problém je, že v Javě se bez Springu nebo jinému Servlet sráči neobejdeš a to převážně kvůli SOAP. A když už tam teda máš JAX-WS, tak potom tam chceš samozřejmě mít i JAX-RS. A jsi v 3,14či. Ve frameworku jako je Spark prostě SOAP nedáš. Na SOAP navíc prostě už potřebuješ reflexi a anotace, protože musíš mít z čeho vygenerovat WSDL, s tím se manuálně štvát nechceš.

Jo a ten Spark mi nastartuje s Jetty za 1 vteřinu. Ale štve mě že Vert.x nad Netty za 2.5 vteřiny. A mimochodem, ono i ta 1 vteřina je hodně, když to porovnám s Go. Teď se to zdá málo, ale jasně to ukazuje, jaký je to pomalý shit, ono se to totiž nastřádá.

Naštěstí alespoň relativně je na tom Java dobře, protože pořád je násobně rychlejší než Python a je v ní mnohem větší pořádek než v Node.js. S .NETem to bude +- srovnatelné, ale tipnu si, že .NET má méně bugů.
Název: Re:Alternativa k Hibernate
Přispěvatel: none_ 05. 08. 2018, 12:29:07
Mel byste si hlavne ujasnit, co chcete delat. V kazdem vasem prispevku to vypada, ze zacinate jinej projekt.
Název: Re:Alternativa k Hibernate
Přispěvatel: andy 05. 08. 2018, 13:02:56
Skusal som teraz profilovat start po tom co som pridal localhost a stale tam mam 1.5s na socketconnect, cize ten hosts file fix nepomaha. Ale co sa mojho pc tyka, tak zjavne je problem hlavne tam. Ale ano, uz z principu bude start v jave pomalsi, lebo je to prvy run, cize interpretovany kod. Mozno skus OpenJ9+AOT. Inac ti "servlet sraci" sa lisia oproti springu prave v tom, ze v idealnom pripade to nastartujes iba raz a potom robis iba redeploy maleho warka, nic nerestartujes.

SOAP som v jave uz dlho nepouzil ale ked to nutne potrebujes, na klienta by ti malo stacit wsimport, alebo mozes pouzit apache cxf. Okrem toho v eclipse existuje wsdl editor, takze ak nie si code first fetisista, da sa aj tak. SOAP je http response ako kazdy iny cize si to mozes spracovat aj rucne (ako xml). Obcas je to aj nutnost, lebo uz viackrat som zazil taky dementny design, ze sa posiela cez response polka sveta bez moznosti pagingu.. Co sa wsdl tyka, uplne staci nahrat vygenerovany subor. Akurat je to neprakticke.

Mel byste si hlavne ujasnit, co chcete delat. V kazdem vasem prispevku to vypada, ze zacinate jinej projekt.
Skor mam pocit, ze mu chyba prax.
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 05. 08. 2018, 13:07:37
No zkusil jsem ten Vert.x (jede to nad Netty) rozjet jak na "localhost", tak na "127.0.0.1" a žádný rozdíl se nedostavil. Používám Windows 7, zkoušel jsem porovnávat perfromance s Linuxem při startu aplikací, ale není to lepší o více než 10%.

Vert.x u mě najede za 1800ms. Ale doba startu opravdu není nejdůležitější údaj...
Název: Re:Alternativa k Hibernate
Přispěvatel: anonym 05. 08. 2018, 13:38:49
No zkusil jsem ten Vert.x (jede to nad Netty) rozjet jak na "localhost", tak na "127.0.0.1" a žádný rozdíl se nedostavil. Používám Windows 7, zkoušel jsem porovnávat perfromance s Linuxem při startu aplikací, ale není to lepší o více než 10%.

Vert.x u mě najede za 1800ms. Ale doba startu opravdu není nejdůležitější údaj...

Ale je to velice důležitý údaj. Protože začne to tím, že 1.5sekundy na start HTTP serveru ti přijde jako OK, a končí to u takové hydry jako je Spring, která v základu s Jersey startuje 4vteřiny, přidáš tam Spring Data JPA a Spring Security a máš to za 6 vteřin, pak tam někdo musí na tu hydru vyrobit něco jako Devtools, což taky není bez chyby. Následně místo toho, abysis pěkně udělal code coverage s integračními testy, tak musíš psát samé Unit testy a mockovat jako blázen, v testech máš bordel, pár integračních testů tam musíš mít stejně, přičemž každý se je bojí spouštět a psát, protože ti každé spuštění sežere hromadu času. A z projektu se stane časem moloch, který kvůli reflexi není deploynutý ani za 20 vteřin. Na ten zpomalený moloch pak potřebuješ různé další nástroje, jako je JRebel. Protože je z toho takový moloch, tak to má bugy a ty u toho nadáváš. A všechno to začalo u té jedné "nedůležité věci", že HTTP server startuje "jen" 1.5 vteřiny a referenční implementace JAX-WS, Jersey, "jen" 3.5 vteřiny.

Nejbizarnější je ten Jersey, který ze 750ms deploye na Tomcat udělá 3500ms deploy. To se na mě nezlobte, ale jak jinak než shit to chcete označit?
Název: Re:Alternativa k Hibernate
Přispěvatel: Filip Jirsák 05. 08. 2018, 13:51:33
Nejbizarnější je ten Jersey, který ze 750ms deploye na Tomcat udělá 3500ms deploy. To se na mě nezlobte, ale jak jinak než shit to chcete označit?
Vy se pořád tváříte, jako že je problém v těch programech a knihovnách, ale přitom je problém ve vás. Ty časy, které tady pořád uvádíte, svědčí akorát o tom, že to neumíte nakonfigurovat. Když do své jednoduché aplikace natáhnete půlku internetu, tak se nedivte, že to pak startuje dlouho. To, že používáte věci, které ve skutečnosti v projektu vůbec nepotřebujete, nebo používáte zbytečně složité knihovny, když by vám stačily jednoduché, je váš problém. Alespoň průměrně inteligentní lidé používají komplexnější knihovny jen na větších projektech, kde jim ty knihovny ušetří spoustu práce, a pár sekund při deployi nikoho netrápí, protože je to v ostatních nákladech jako kapka v moři. Že neumíte programovat a místo toho se jenom snažíte poslepovat vygooglené knihovny, to je čistě váš problém, ne problém těch vygooglených technologií.
Název: Re:Alternativa k Hibernate
Přispěvatel: f 05. 08. 2018, 13:52:20
To je fakt jak u retardů. Koho zajímá nějaký deploy? Java se nasadí a jede třeba měsíc. Není důvod to dělat jinak. Pokud někdo pouští integrační testy stokrát za minutu, tak by měl zkusit třeba prodávat, možná mu to půjde lépe. Trvá to, co trvat má. Pokud by to nic neumělo, bylo by to hned. Možná neumíš využít to, co to umí?
Název: Re:Alternativa k Hibernate
Přispěvatel: tralala 05. 08. 2018, 14:05:51
Nejbizarnější je ten Jersey, který ze 750ms deploye na Tomcat udělá 3500ms deploy. To se na mě nezlobte, ale jak jinak než shit to chcete označit?

Kup si silnejsi pocitac
Název: Re:Alternativa k Hibernate
Přispěvatel: Ondrej Nemecek 05. 08. 2018, 16:39:35
A všechno to začalo u té jedné "nedůležité věci", že HTTP server startuje "jen" 1.5 vteřiny a referenční implementace JAX-WS, Jersey, "jen" 3.5 vteřiny.

Omyl, všechno trápení začalo tím, že se člověk narodil :D :D :D