--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8E947B86-2228-4DD3-9D6A-C1B6D757652E%40gmail.com.
Sorry if I understand stuff incorrectly, but:
I agree with Adam where he discusses migration issues, but I also
don't see how "DEFAULT_AUTOFIELD" setting could leave tables out
of the migration(s).
My understanding is that it would cause immediate re-provisioning of all the pk fields, including in the core django modules and third-party modules. Some of them might have programmed their logic such as to include some integer math around the primary keys (and now all auto primary keys might be GUID).
If I understand the above correctly, the setting would have to be per-module. Could it simply be done like this:
class PKMixin(object): id = models.UUIDField(primary_key=True, ....)
Naturally, then all desired models would (also) derive from this
mixin. A bit of a chore, but it would not require reconfiguration
of all migrations, just the ones the programmer would specify -
and would only be limited to their own module.
OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively easy to modify makemigrations code detect existing migrations for the model, detect that the only difference is IntegerField vs PositiveIntegerField and in this case skip generating the migration (for migrating the field to an unsigned one). There could also be a flag to the management command specifying to force generating said migrations.
Of course, ignore if this is gibberish.
LP,
Jure
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0VqXrPbre-6YXSSnu2PBStQoijjoEH_9Wc-aB0gDEHBw%40mail.gmail.com.
primary keys might be GUID
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/69378e21-2b2c-2604-18c8-16c6efc03a11%40gmail.com.
Jure - yes switching the setting should generate migrations for all affected models. The migration guide would cover changing models' primary key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as you've suggested. Maybe Django should provide such a mixin to ease the migration.primary keys might be GUIDThe proposal is not to move to GUID's/UUID's, as you've used in your example. It's to move to bigger integers.UUID's are a bad idea for database performance, as they distribute randomly across the table, preventing any cache wins. On autoincrement tables, the tail end of each table is normally most frequently read and written and thus cached in memory. I don't think Django should ever suggest UUID's as primary keys.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8E947B86-2228-4DD3-9D6A-C1B6D757652E%40gmail.com.
--
Adam--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0VqXrPbre-6YXSSnu2PBStQoijjoEH_9Wc-aB0gDEHBw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/69378e21-2b2c-2604-18c8-16c6efc03a11%40gmail.com.
--Adam
An alternative is to have something on the AppConfig. I'm sure for most people the large tables that may need this will be in their own, rather than third-party, apps. People can also choose to set this for a third-party app by subclassing the AppConfig, but as you say, they'd then be forced to handle migrations manually - is this even avoidable? I'm not sure how this would look for moving to a new default though.
Ah. I hadn't thought about that - only got as far as being able to define a new default value in DEFAULT_AUTOFIELD in the start project template so that existing projects are not suddenly forced to migrate.
An alternative is to have something on the AppConfig. I'm sure for most people the large tables that may need this will be in their own, rather than third-party, apps. People can also choose to set this for a third-party app by subclassing the AppConfig, but as you say, they'd then be forced to handle migrations manually - is this even avoidable? I'm not sure how this would look for moving to a new default though.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dfb45121-8ce6-4d6b-8505-5831778e4c3f%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJ%3D9zicjm4nWYRD9FM0EcMVFbWtj8wPHB084P%2BC_5x9wLgrgPQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7c2f1424-4d48-40eb-832a-d7bbe492d0c5%40Spark.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7c2f1424-4d48-40eb-832a-d7bbe492d0c5%40Spark.
An explicit `id = PositiveBigIntegerField(...)` workaround would be fine to be honest, for those that need it.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJMrob2w9qtp2ohHmQSqh%3DzqSAaBbJ1TzXmTPzJfuP4TvA%40mail.gmail.com.
I also don't think this is necessary any more and can be closed.An explicit `id = PositiveBigIntegerField(...)` workaround would be fine to be honest, for those that need it.I also would like to meet the django app that *does* need it (for non-silly reasons like deciding to start ID's near 2^63).
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2a5a9a02-70d6-4f77-9af0-c9217cb9eb3an%40googlegroups.com.