Se debe incluir la información estándar nacional

[jhonnattan123]

el estado de chile posee un estándar para identificar cada comuna, provincia y region.

http://www.subdere.gov.cl/documentacion/c%C3%B3digos-%C3%BAnicos-territoriales-actualizados-al-06-de-septiembre-2018

pienso que esta información debe incluirse pero el drama es que esta cambia cada poco tiempo. entonces propongo que cada objeto posea un atributo que indique su versión ejemplo

{
    "id": 1,
    "regionId": 1,
    "provinciaId": 1,
    "name": "Arica",
    "description": "Comuna de Arica",
    "code_20180101": "15101"
  }

[vicasas]

@jhonnattan123 ¿Para que escenarios seria necesario agregar los ids de las provincias y comunas? Me hace más sentido de momento agregar el id de la región quizás en número romano mediante una key adicional.

Para lo que planteas de agregar code_20180101 que tan recurrente seria ese cambio dado que indicas que es un cambio que ocurre en poco tiempo.

[jhonnattan123]

Desde la ley N.º 20.050 de 2005 que elimina el número romano en las regiones, se comenzó a facilitar la creación de regiones y comunas.

https://es.m.wikipedia.org/wiki/Historia_de_la_organizaci%C3%B3n_territorial_de_Chile

Generando cambios en 2007 2009 hace poco en 2018

Pero existen en propuesta y discusión cerca de 12 nuevas regiones.

Y eso es algo que rompe muchas cosas sobre todo de trazabilidad, históricos etc. Y una de las razones por las cual es necesario ese código y una de las principales es por temas contables. Para emitir boletas, facturas etc. También para asociar data relacionada con temas legales y gubernamentales. Por eso creo que se debería incluir, pues ahorraría la necesidad de una tabla de rompimiento para estos casos y haría más atractiva la librería.

[vicasas]

@jhonnattan123 Me tinca tu observación! 😁 ¿podriamos definir como se deberian llamar las keys para cada obj (regiones, provincias y comunas? ¿Y si deberia enlazarse los datos mediante estos ids y no los genericos actuales?.

Con relación a este último (comunas) ¿podría haber otra forma de evitar tener que tener N keys con el codigo cada vez que cambian o crees que se deberia manejar ese historico de cambios?

Ejemplo... si cambio el id de la comuna A deberia ir la key code_20201118 asumiendo que hoy se hizo ese cambio PERO en 3 días más sufre otro cambio, creamos otra key code_20201121 quedando la anterior en el mismo obj. ¿? Lo pregunto por que no me parece optimo.

[jhonnattan123]

tienes razón, podría crecer mucho. quizás agregando una especie de base de datos de logs de cambios y un objeto de configuración que cual se pase en los metodos. ej:

DB LOGS:

let arrLog =  [{
     date : "2020-01-21",
     strAffectedType : "rename",
     strDivisionType: "comuna",
     strDescription: "se cambio el nombre de la comuna, de Arica a Ariquita",
     intID : 2,
     objBeforeData: {
          ...la data de la comuna antes de ser modificada
     },
     objAfterData: {
          ...la data de la comuna después de ser modificada
     }
},{
     date : "2020-11-19",
     strAffectedType : "created",
     strDivisionType: "comuna",
     strDescription: "se creo la comuna de el oso polar",
     intID: 86.
     objData: {
        ...la data de la comuna
     }
},{
     date : "2023-01-25",
     strAffectedType : "merged",
     strDivisionType: "comuna",
     strDescription: "se fusiono arica con iquique",
     intID: 2........
}]

y para rescatar esta información podría ser por ej::

function getProvincias(id, objConfig);

siendo objConfig un objeto opcional que permita múltiples cosas, entre ellas rescatar la historia. asi como incluir la información territorial gubernamental estándar de manera opcional

let objConfig = {
     bolGetHistory: true, //default false
     bolGetChildrens: false, //default false
     bolIncludeGobCodes: true //default true (y siempre obtendría el código estándar mas actual y)
     strCut: "2020-01-18" // default is today (con esto podríamos elegir la fecha de la data obtenida)
};

igual me parece que todo esto quizás sea muy complejo y muy puntual, aunque con el tema de la nueva constitución y los conflictos sociales, quizás haya durante los próximos años muchos cambios en la estructura nacional, haciendo que este comience a convertirse en un problema mas común. pero almenos así la librería se convertiría en algo mas serio, y entregar mas confianza a los desarrolladores que no habrá problemas a largo plazo haciendo que opten por esta.

[vicasas]

@jhonnattan123 Estuve pensando harto sobre esto, pero me parece poco mantenible el tema del logs de cambio, en algún punto va a llegar a ser tan grande que hará poco a poco a esta pequeña librería algo más pesado, cosa que no pretendo hacer.

Si me parece que se deben agregar los ids para regiones y provincias y así poder relacionar los datos entre si usando los mismos. Para los ids de las comunas lo que se me ocurre de momento es agregarlos pero para cualquier cambio de ellos es comprometernos a tenerlo actualizado, pero sin mantener un registro de cambio.

[jhonnattan123]

@jhonnattan123 Estuve pensando harto sobre esto, pero me parece poco mantenible el tema del logs de cambio, en algún punto va a llegar a ser tan grande que hará poco a poco a esta pequeña librería algo más pesado, cosa que no pretendo hacer.

Si me parece que se deben agregar los ids para regiones y provincias y así poder relacionar los datos entre si usando los mismos. Para los ids de las comunas lo que se me ocurre de momento es agregarlos pero para cualquier cambio de ellos es comprometernos a tenerlo actualizado, pero sin mantener un registro de cambio.

si, pensandolo biem. creceria mucho el tema de lo historico. ¿quisas dejar un .zip almacenado en otro repositorio o plugins para quien requiera ese tema puntual?

pero volviendo al tema principal:

entonces agregar la id territorial del gobierno, pero, ¿remplazando la actual? o dejandolo como valor de solo lectura? ¿o posibilitando mediante un objeto de configuracion cual usar?

[vicasas]

@jhonnattan123 Para la parte del log me parece que esta fuera del scope en estos momentos, podríamos darle una vuelta más en el futuro.

Con respecto a lo segundo seria incluir el id estandar que le corresponderia a las Regiones, Provincias y Comunas. Este deberia reemplazar los actuales existentes y poder relacionar los datos con estos nuevos valores.

Se me ocurre mantener la key de nombre id. Y dejare este issue como una mejora.

Adicional a lo anterior, ¿Podemos confiar en la información que esta alojada en esa url?