StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>Edited</strong>. So I'm still not quite clear on your table structure - that's what has thrown me when I wrote the initial answer.</p> <p>My understanding is that your <code>Language</code> table look something like:</p> <pre><code>Id -- this is a PK of entity (e.g. Accessory) this entry provides localization info for Type -- string constant describing entity type (e.g. "accessory") Language -- language code Value -- actual localized string </code></pre> <p>Does that look about right? If so, this raises the question on how you intend to localize <strong>multiple</strong> fields within the same entity. Shouldn't you at least have another column linking to property (field) name?</p> <p>At any rate, <code><formula></code> is indeed not supported as part of the <code><key></code> (I could have sworn that is is) so your options here are pretty limited:</p> <ol> <li>Use a <a href="http://docs.jboss.org/hibernate/stable/core/reference/en/html/querysql.html#querysql-load" rel="nofollow noreferrer">custom loader</a> - this is probably the most straightforward approach.</li> <li>Add <code>type</code> as an actual column on your <code>Accessory</code> table and map it as part of composite id; you can then map <code>Language</code> map using composite key. Should work but is rather ugly.</li> <li>Rethink your approach. Do you <strong>really</strong> need to load a map of languages every time? Seems like doing it as a separate query (or even direct <code>get()</code> assuming appropriate composite id) for <strong>current</strong> language would be easier and (with adequate caching configuration) a lot faster.</li> </ol> <p><strong>Update</strong> To elaborate on #3 above:</p> <p>First of, let me clarify this - I'm assuming your localized strings are user-editable at runtime. If that's not the case, I'd strongly recommend forgoing the table altogether and going with resource bundles instead.</p> <p>I'd map <code>Language</code> as a separate entity with <code>type</code>, <code>id</code>, <code>language</code> and (if you need to do this for multiple properties) <code>property_name</code> as parts of composite id. The actual localizable property on your entity (e.g. <code>ProductName</code> on <code>AccessoryType</code>) would be transient. You can then manually load the appropriate localized string for your entity by doing something like:</p> <pre><code>AccessoryType accessory = ...; Language language = (Language) session.get(Language.class, new LanguageKey("accessory", accessory.id, "en_US", "productName")); accessory.setProductName(language.getValue()); </code></pre> <p>You can even do that in the <a href="http://docs.jboss.org/hibernate/stable/core/reference/en/html/events.html#objectstate-events" rel="nofollow noreferrer">event listener</a> assuming that currently selected language is globally obtainable (via global or thread local call) - it will then happen auto-magically for all you entities. If the language table is reasonably small, you can have Hibernate <a href="http://docs.jboss.org/hibernate/stable/core/reference/en/html/performance.html#performance-cache" rel="nofollow noreferrer">cache it</a> and you won't even incur database hits on this.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload