[SERVER-8976] Store multiple internationalized values in a single field Created: 14/Mar/13  Updated: 06/Dec/22  Resolved: 07/Mar/17

Status: Closed
Project: Core Server
Component/s: Usability
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor - P4
Reporter: Kevin Stembridge Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Participants:

 Description   

I have a use case where I need to store records in the database that have a field whose value must be internationalized. So, for a given record this field will have multiple possible values based on the number of Locales I want to support.

For example, imagine a business can provide services such as Watch Repair and Jewellery Repair.

To internationalize these in a static fashion I could have the following properties files:

messages_en.properties
watch.repair=Watch Repair
jewellery.repair=Jewellery Repair

messages_en_US.properties
jewellery.repair=Jewelry Repair

However, I need to be able to create these records dynamically and store them in the database without having to update any static resource bundles. To store these in a Services collection in the database my name field could contain the lookup key 'jewellery.repair'. The application could then retrieve the record and use the standard ResourceBundle mechanism to lookup the internationalized value.

That works fine when retrieving single records or even multiple records, but I run into a problem when I want to do a pagination query sorted by the internationalized field. Its not possible to do that at the database level. I would have to retrieve everything into memory, do the i18n, sort, then sublist. A similar problem occurs if I want to search for services by name. There is no simple way to find a record by name where the given search criteria is internationalized.

I don't think there's any way to solve this at the application level. I think the right way to solve it is for the database to introduce the concept of an internationalized field.



 Comments   
Comment by Ian Whalen (Inactive) [ 24/Feb/17 ]

Kevin, without the details of the schema, use case, and query, it's difficult to make any progress on this request. If you're still interested in this, could you please provide these details to help us understand the query you wish to run but cannot?

Generated at Thu Feb 08 03:18:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.