I\'m new to Core Data, and am struggling with some of it conceptually (relative to, say, SQL, which I understand).
I\'m trying to build a model which for the sake o
I don't know if I qualify as somebody who groks core data but I've used something like this in the past:
name
in Something
is the english name. So I don't have to search the relationship in english language devices (which covers 70% of the devices for my app).
And there is a getter called localizedName
in the Something
subclass that either returns name or the string for the currently used language code.
When I did this I thought that I could save the localized string in the name property because languages usually don't change often on devices that are not used by developers. But finally I decided against this because that wasn't a performance problem.
Another variant I thought I could use to fight against non-existing performance problems:
currentLanguageString basically points to the localized string of the current language. It is changed everytime the language changes (in 99.9% of all cases this happens one time, when the app is first launched).
if you have more than one string in the Something
entity I would make LocalizedString
an abstract parent class of subclasses specifically created for the string you want to localize.
You have to use such strange constructs because you can't create a relationship to more than one entity.
Or if you know what you are doing, ignore the "no inverse relationship" warning
but if you go this way you have to make sure that you never delete a LocalizedString
object that is still in use. You don't want to end with an inconsistent storage.