¿Cómo se representa un tipo de cadena localizada en Datos básicos?

Question

Soy nuevo en Core Data, y estoy luchando con algo de esto conceptualmente (en relación con, digamos, SQL, que entiendo).

estoy tratando de construir un modelo que en aras de la simplicidad se ve así:

"Category" entity, which has a name, and a relationship to-many Products 
"Product" entity, which has a name 

Quiero esos name s (cuerda) de ambas entidades para almacenar variantes localizadas. Eso implica otra unión. Hay un pequeño número de localizaciones posibles. Sé que podría poner cada localización como un atributo individual ("name_en", "name_de", etc.), pero eso no se escala, y quiero entender la forma "correcta" de lograr esto.

Mi instinto me dice que quiero dos entidades más aquí, una Localizaciones uno (que simplemente contiene el conjunto de posibles localizaciones) y algún tipo de LocalizedString uno, que se relaciona con la Localización. Pero Xcode me advierte acerca de no tener relaciones inversas configuradas, etc.

¿Alguien puede asimilar profundamente el diseño del modelo de Core Data por favor ayude a un novato a entender cómo pensar en este problema?

(Mi siguiente problema será la construcción de la interfaz de usuario multi-giratoria extraña que le permite establecer el nombre para cada localización que está disponible, pero eso será otro conjunto de investigación. :))

Answer 1

No sé si califico como alguien que asimila datos básicos pero yo he usado algo como esto en el pasado:

name en Something es el nombre Inglés. Así que no tengo que buscar la relación en los dispositivos de idioma inglés (que cubre el 70% de los dispositivos de mi aplicación).
Y hay un getter llamado localizedName en la subclase Something que devuelve el nombre o la cadena del código de idioma actualmente utilizado.

Cuando hice esto, pensé que podría guardar la cadena localizada en la propiedad del nombre porque los lenguajes no suelen cambiar con frecuencia en los dispositivos que los desarrolladores no usan. Pero finalmente decidí no hacerlo porque ese no era un problema de rendimiento.

Otra variante pensé que podría utilizar para luchar contra los problemas de rendimiento no existentes:

currentLanguageString básicamente apunta a la cadena localizada del idioma actual. Se cambia cada vez que cambia el idioma (en el 99.9% de todos los casos esto ocurre una vez, cuando la aplicación se lanza por primera vez).

---

si tiene más de una cadena en la entidad Something me gustaría hacer LocalizedString una clase padre abstracta de las subclases creados específicamente para la cadena que desea localizar.
Tienes que usar construcciones tan extrañas porque no puedes crear una relación con más de una entidad.

---

O si usted sabe lo que está haciendo, ignorar la "relación inversa", advirtiendo

pero si usted va esta manera usted tiene que asegurarse de que nunca elimina un objeto LocalizedString que todavía está en uso. No quiere terminar con un almacenamiento incoherente.