[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 messages_en_US.properties 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? |