[Javalist] JPA & i18n

[Gábor Garami]

Az egyik non-obtrusive megoldas, hogy az entitasokhoz hozzaadsz egy
language oszlopot, aminek van egy default erteke, ami a most aktiv
nyelv, es a meglevo JPQL lekerdezeseket kibovited, hogy az aktualis
locale alapjan keressen neked. Nem is kell feltetlen numerikus ID-ket
hasznalni, nyugodtan atveheted a Locale class nyelvkodjait, _annyival_
nem lesz lassabb, foleg, hogy teljes matchet keresel.

A masik tenyleg az, hogy kulon tablakat gyartasz, de ez szvsz
felesleges bonyolitas.
Garami Gábor
E-mail: gabor.garami at hron.me
Tel: +36 20 235 9621
Skype: hron84


2015-08-28 10:11 GMT+02:00 Tamás Bódis <tamas.bodis at gmail.com>:
> Sziasztok,
>
>    egy több éves projekt többnyelvűsítéséről lenne szó. A cimkék,
> hibaüzenetek többnyelvűsítésével nincs is gond. Ami probléma az az adatbázis
> szinten tárolt adatok több nyelven való megadhatósága. A neten körbenézve
> úgy tűnik mindenki valami "szép" normalizált megoldást javasol (globális 1
> nyelvi tábla vagy épp táblánkénti nyelvi táblával). Ezek a megoldások az
> egyszerű lekérdezéseknél (entity cache-el megtámogatva mondjuk)
> működőképesek, de ha elkezdünk olyan JPQL-eket futtatni ahol a szöveges
> mezőkre is futna query.... no  akkor elég csúnya SQL-ek jönnek ki a
> Hibernate-ből (Query cache esetünkben nem sokat segít, mert a mögöttes
> entitások azért változékonyak).
>
>   A fenti "csúnya sql" problémától eltekintve a megoldás működőképest csak
> nem tetszik amit látok. Valami szebb / okosabb tervezési megoldásra
> javaslat?
>
>   Olyan megoldás is felmerült, hogy a tábla szöveges mezőit egy JSON
> struktúrává alakítanán. Lekérdezésekkor ez a struktúra hatékony csak a
> java-nak van picivel több feladata a JSON->objektum konverzióval. Viszont a
> keresés így sem jobb, mert nem ismerek JSON-ban kereső JPQL megoldást
> (maximum a "like"-ot)
>
> Köszi!
> // Tamás
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>