switching foreign key to a more universal and unique id which is geon…

[abderraxim]

…ame_id as local id would mess up the related data on other models if database repopulation

[jpic]

Interesting but doesn't this also require a data migration? Le ven. 7 juin 2024, 22:25, NABIH Abderrahim ***@***.***> a écrit :

…

…ame_id as local id would mess up the related data on other models if database repopulation ------------------------------ You can view, comment on, or merge this pull request online at: #290 Commit Summary - 818f733 <818f733> switching foreign key to a more universal and unique id which is geoname_id as local id would mess up the related data on other models if database repopulation File Changes (2 files <https://github.com/yourlabs/django-cities-light/pull/290/files>) - *M* src/cities_light/abstract_models.py <https://github.com/yourlabs/django-cities-light/pull/290/files#diff-c27f7450a6aad926c88514ebb6c1c28d1c4b9ba05a4423e6dd32537f32dd069f> (12) - *M* src/cities_light/management/commands/cities_light.py <https://github.com/yourlabs/django-cities-light/pull/290/files#diff-ecc390657d9b9b8038c4067f01edbed214bee5b99b90716c7b440ac60ab63704> (8) Patch Links: - https://github.com/yourlabs/django-cities-light/pull/290.patch - https://github.com/yourlabs/django-cities-light/pull/290.diff — Reply to this email directly, view it on GitHub <#290>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXDLBRP6IXOLK4JZ6HK33ZGIJLRAVCNFSM6AAAAABI7IKTSGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2DCMJRGEYTAMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[abderraxim]

Yes indeed ,i will do that later

[jpic]

In such situation, I've found useful to divide the migration in 3 operations: - creating a new column - copying the data - dropping the old column It would be interesting to know how long such a migration can take Le dim. 9 juin 2024, 19:25, NABIH Abderrahim ***@***.***> a écrit :

…

Yes indeed ,i will do that later — Reply to this email directly, view it on GitHub <#290 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXDLBODEMCJ6WCYYE2OXDZGSFZPAVCNFSM6AAAAABI7IKTSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWG4YDOOBYGM> . You are receiving this because you commented.Message ID: ***@***.***>

[abderraxim]

pardon me but i don't get the idea, if we're just switching to another key column , i'm not replacing the id key generated, but just defining the column to rely on

[jpic]

Yes but what happens to the existing data which relies on the old column? Don't the Fks need to be migrated? Le lun. 10 juin 2024, 00:34, NABIH Abderrahim ***@***.***> a écrit :

…

pardon me but i don't get the idea, if we're just switching to another key column , i'm not replacing the id key generated, but just defining the column to rely on — Reply to this email directly, view it on GitHub <#290 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXDLBHIKP6JLY5GV372T3ZGTJ7XAVCNFSM6AAAAABI7IKTSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWHAYTSNRRHA> . You are receiving this because you commented.Message ID: ***@***.***>

[abderraxim]

they should implement the migration or they can just explicitly specify the to_field and continue with the old model

    country = models.ForeignKey(
        Country, on_delete=models.DO_NOTHING, blank=True, null=True, to_field="id"
    )
    region = models.ForeignKey(
        Region, on_delete=models.DO_NOTHING, blank=True, null=True, to_field="id"
    )
    subregion = models.ForeignKey(
        SubRegion, on_delete=models.DO_NOTHING, blank=True, null=True, to_field="id"
    )
    city = models.ForeignKey(
        City, on_delete=models.DO_NOTHING, blank=True, null=True, to_field='id')