Author Archives: admin

Hibernate a jednosměrné one-to-many vztahy

Dnes nebudu psát nic světoborného. Jen bych uvedl na pravou míru chybu, které jsem se dopustil v minulém článku. Není pravda, že Hibernate neumí jednosměrné one-to-many vztahy bez použití join tabulky, naopak je to docela snadné.

Na svoji obhajobu mohu uvést jen to, že jsem to v době psaní článku moc neřešil a narazil jsem na dokumentaci, která naznačovala, že to není nijak moc jednoduché. A hlavně, abych nevypadal jako úplný blbec, ponořil jsem se do specifikace EJB 3.0. Tam jsem na straně 185 našel následující text

Unidirectional one-to-many relationships may be implemented using one-to-many foreign key mappings, however, such support is not required in this release. Applications that want to use a foreign key mapping strategy for one-to-many relationships should make these relationships bidirectional to ensure portability.

Takže se mohu vymlouvat, že jsem tu relaci udělal obousměrnou, abych zařídil přenositelnost.

Ale dost už bylo výmluv, podívejme se na to jak ono mapování zařídit. Připomenu jen, že vytváříme třídu Client, která obsahuje kolekci adres a účtů (viz. obrázek)
@Entity
@Table(name="client")
public class Client {

@Id @GeneratedValue(strategy=GenerationType.AUTO)
private Integer id; @Column
private Long personId;

@Column
private String name;

@OneToMany(cascade=CascadeType.ALL)
@JoinColumn(name=“client_id”, nullable=false)
@BatchSize(size=10)
private Set<Account> accounts = new HashSet<Account>();

@OneToMany(cascade=CascadeType.ALL)
@JoinColumn(name=“client_id”, nullable=false)
@BatchSize(size=10)
private Set<Address> addresses = new HashSet<Address>();

public void addAddress(Address address)
{
addresses.add(address);
}
//zbytek vynechán
}

Všimněte si prosím anotace @JoinColumn(name=”client_id”, nullable=false), která nám zajistí požadované mapovaní přes cizí klíč. Důležitý je druhý atribut – nullable. Ten Hibernatu říká, že cizí klíč client_id v tabulce address nesmí obsahovat null.

Oproti minulé verzi vidíme značné zjednodušení. Nemusíme se starat o plnění druhého směru relace. Dokonce ani neuděláme stejnou chybu jako já minule, když jsem zapomněl vyřešit předávání adresy mezi klienty (automatické odebrání adresy jednomu klientovi, při přidání druhému). Abych to ještě více zjednodušil, použil jsem přehlednější, i když méně výkonnou, formu inicializace množiny adres.

Takže pro shrnutí, jednosměrná one-to-many relace v Hibernate funguje, nicméně není přenositelná v rámci EJB 3.0. Ještě bych chtěl na závěr poděkovat Markovi L. za to, že mě upozornil na spoustu chyb v minulém článku a ukázal mi, že by to mapování měl Hibernate přeci jenom umět.

Zdrojové kódy můžete stáhnout zde.

Zdroje:

  1. JSR 220: Enterprise JavaBeansTM,Version 3.0
  2. Hibernate dokumentace
  3. EJB 3.0 – still trying to catch up to JDO and Hibernate
  4. Getting Started with Hibernate

Neposlouchejme módu, používejme rozum

Nenoste bokovky a tričko nad pupík, když na to nemáte postavu.

Všimli jste si, jak se programování řídí módou? Je to skoro jako v oblékání. Svět se najednou zblázní a všichni se začnou oblékat stejně. Hitem letošního léta je AJAX a SOA. Kdo je nepoužívá, je úplně out. Ti největší frajeři používají AJAX pomocí SOA nebo naopak. Anotacemi také nic nezkazíte. Hlavně nesmíte přiznat, že ještě používáte XML. Pokud vám na to přijdou, od největšího společenského opovržení vás může zachránit jedině aplikace skriptovacích jazyků. Nebo cokoliv na kolejích. Nebo pastelové barvy. Zajímavé je, že čím méně pochopitelná věc je, tím je módnější. Kdysi to bývaly EJB, teď je to SOA. (Tušíte někdo co je SOA?)

 

Stejně jako v módě člověk neví, jestli jsou věci módní kvůli lidem nebo proto, že si tak rozhodli nějací marketingoví odborníci. Nicméně důsledek je jediný. Člověk (nebo firma) je nervózní, že mu ujíždí vlak. Říká si, jak to, že ještě nepoužívám XYZ? Všichni ostatní už to mají. Pak už je jen krůček od toho, aby začal hledat využití pro onu moderní, naprosto nejlepší, všechny problémy řešící technologii. Je to jako mít kladivo a hledat hřebík na zatlučení, protože vidím, že všichni ostatní už kladiva používají.

 

To je samozřejmě postavené na hlavu. Technologii bychom měli volit podle problému, který potřebujeme řešit. Tzn. mám hřebík a hledám kladivo, kterým by šel nejlépe zatlouci. Pokud postupuji naopak, riskuji jednu ze dvou variant. Buď budu řešit problém, který řešit nepotřebuji nebo použiji špatný nástroj. Takže buď budu zatloukat hřebíky, které zatloukat nepotřebuji. Nebo se budu snažit kladivem přestřihnout drát. Nejhorší možnost je, když tím kladivem drát opravdu umlátím a pak vydám článek, jak je to úžasné, že moderní kladivo se dá použít i na střihání drátů.

 

Proto prosím, používejme rozum. XYZ je určitě skvělá věc, ale má smysl ji použít jenom pokud mi pomůže vyřešit nějaký problém. Nemá cenu cpát zákazníkovi něco co prostě nepotřebuje (já jsem programátor, ne obchodník). Takže až budete příště cítit nutkání použít XYZ tak se zamyslete, jestli je to opravdu potřeba. To, že na konferencích nemluví o ničem jiném, neznamená, že se bez toho nedá žít. Znamená to jen, že je to novinka a oni prostě nechtějí mluvit o věcech, o kterých už mluvili už vloni.