Názory k článku JavaFX: Hibernate – ukládání nových záznamů, úvod do H2 databáze

Mel bych vyhrady k praci s ID:
1. Short neni uplne vhodny - naopak se pouziva Long (ale to je kosmeticke)
2. proc sakra vytahuje ID rucne? Pokud ho v objektu nevyplni tak ho hibernate sam nastavi (pokud je strategie AUTO)
3. kdyz uz takovouhle zbytecnou metodu, to ji nedokaze udelat generickou? To by byla pro zacatecniky zajimava ukazka
4. technickej detail: pokud si vytahne maxID a pricte 1 tak metoda by se nemela jmenovat max ale next

1. Když vím, že tam nebude nikdy více než třeba 10k položek, tak je to zbytečné
2. Souhlas
3. Souhlas
4. Tohle už je jenom detail, zažil jsem i mnohem hůře pojmenované metody vzhledem k tomu, co dělaly

Mozna mi neco uniklo, ale bude to vubec pracovat spravne? Precte ID, zvysi o 1, zapise zaznam s novym ID. Fajn, to je cele v transakci nebo co se stane pri 2 a vice uzivatelich? btw bych to takto stejne neresil, spis nejakej autoinkrement primo v DB.

To je řešeno tímto:
...jedná se o automaticky zvyšovanou hodnotu, která není nikdy znovu použita ani v případě, že se vrací zpět nedokončená transakce.

Podla mna je toto brutalna prasacina. Robit inkrementaciu ID v aplikacii... V MySQL to ma na starosti autoincrement a v mongo a podobnych databazach to ma taktiez na starosti samotna databaza.
Nechce sa mi verit, ze by Java bola natolko specialna, ze si musi aplikacia sama robit autoinkrement.

Vy pořád nechápete, že tohle je seriál, který konzistentně ukazuje, jak se programovat _nemá_. :D

Java (JDBC) toto samozrejme nijak neresi, proste zapises zaznam _BEZ_ uvedeni ID a ted se dopocita automaticky (kdyz mas autoinkrement). Proto me zarazila tady ta aplikace, ktera drze vypisuje ID na GUI jeste pred zapisem ;) Navic shorty, no osobne jsem v Jave short pouzil tak na 50 mistech, a to v ni profi delam 15 let. (tudiz 50 pouziti je 0.0 nic :), tady v serialu je to porad.

S tím shortem je občas legrace. To máte kupříkladu skladový systém, kde každá lokace má short id. Autoři předpokládali, že více než 30000 skladových lokací nikdo nikdy nebude potřebovat. Natolik skálopevně, že to omezení nenapsali do seznamu vlastností. A to pak koupíte pár poloautomatických karuselových regálů a těšíte se, jak vám to zjednoduší práci. A ono ejhle, ono ne.

Co se ID týká, tak záleží na technologii a zvycích. Naše aplikace ukazují ID předem také. Generuje je pro nás Oracle pomocí sequence. Akorát se pak musíte připravit na to, jak vysvětlit zákazníkovi, že když neuloží objednávku 10, tak už ji nikdy nezaloží, protože další bude mít číslo 11. Vědět ID předem vám umožní vytvořit záznam o zakázce (=zápis do 5 tabulek) "najednou". Pokud ho generuje databáze při insertu, tak pak máte kroky: insert into header, select id from header, insert into detail. V každém případě se ale shodneme, že ID nemůže generovat klient.

Klid hoši, máme nový dyzajn! A ten je přece cool! Tak nevim, proč řešit takéto prkotiny... :)

Spousta lidí přede mnou už řekla, že přičítání +1 k ID v kódu je špatně, ale už neřekla proč:

Takže: hlavní důvod je ten, že pokud si klienta otevřou dva uživatelé a oba kliknout na "Nový záznam", tak oba dva dostanou stejné ID.
Proč? Ani jeden z nich totiž ještě neklikl na "Uložit", takže data v tabulce se nezměnila.
Tímpádem oba zjistí stejné poslední ID, oba udělají +1, a oboum vyjde stejný výsledek.

Pro toho, kdo klikne jako první na "Uložit", to bude fungovat a záznam se úspěšně založí. Ten, který klikne na "Uložit" jako druhý, dostane chybu z databáze, protože se nedá provést INSERT s již existujícím ID.

Řešení je několik (Hibernate jich podporuje hned několik) - z těch jednodušších:

- další číslo si nechat generovat databází (pokud má tu featuru)

- jako ID používat UUID, které se vygeneruje vždy jedinečné