Automatic primary keys at model inheritance
Hello, I am using django 1.1 and I discovered this problem: I have models like these --- class Place(model.Models) ... class Restaurant(Place) ... class Bar(Place) ... --- the primary key counters for Restaurant and Bar classes are separated, which causes me troubles, because I want a Place to be Restaurant or Bar not both. Example: I create first Restaurant it has pk (place_ptr_id) = 1 and its Place has pk (id) = 1 Then I create first Bar and it has pk (place_ptr_id) = 1 and its Place has pk (id) = 1 instead what I expect (Bar.place_ptr_id = Place.id = 2). I think this may cause a lot of trouble in case you want to have multiple children models for one parent model (even if you want Place to be both, Restaurant and Bar, because there is not an easy way to extend Place to Bar, when you have a Restaurant or Place, or I have not found it). I wonder if it is bug or a feature. If it is feature I can not find out what is it useful for. Vlastimil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Migrations for multiple Django versions
Hi everyone, we are trying in our application to support multiple Django versions, specifically 1.7 to 1.9. But we encountered a problem with `User.last_login` field. We use custom User model based on `AbstractBaseUser` as specified by the documentation. Everything was fine in Django 1.7, but we got stuck when we wanted to add support for Django 1.8, where the `last_login` was modified to allow NULL values. As recommended by https://docs.djangoproject.com/en/1.10/topics/migrations/#supporting-multiple-django-versions we have migrations generated in Django 1.7 (lowest supported version) an thus `last_login` is NOT NULL, but that causes tests to fail when run in Django 1.8/1.9, since code allows `last_login` to be NULL. We can't even redefine the field in our model, which would be the most straight forward solution, but that's not allowed by Django either. What's the correct solution for this problem? It looks to us like there are some unresolved issues regarding the model and migrations design. Thanks for any suggestions Vlastimil -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cb797b9c-9b7e-47f3-85ca-3c9fedef6c9c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations for multiple Django versions
Is that an official solution for migrations based on Django version? Probably works, but it doesn't look like a nice solution. Regards, Vlastimil Dne středa 19. října 2016 1:57:25 UTC+2 Tim Graham napsal(a): > > Assuming the problem is makemigrations generating different migrations > based on the Django version, conditionally adding operations in migrations > with some django.VERSION checks may help. > > On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote: >> >> Hi everyone, >> >> we are trying in our application to support multiple Django versions, >> specifically 1.7 to 1.9. But we encountered a problem with >> `User.last_login` field. We use custom User model based on >> `AbstractBaseUser` as specified by the documentation. Everything was fine >> in Django 1.7, but we got stuck when we wanted to add support for Django >> 1.8, where the `last_login` was modified to allow NULL values. As >> recommended by >> https://docs.djangoproject.com/en/1.10/topics/migrations/#supporting-multiple-django-versions >> >> we have migrations generated in Django 1.7 (lowest supported version) an >> thus `last_login` is NOT NULL, but that causes tests to fail when run in >> Django 1.8/1.9, since code allows `last_login` to be NULL. >> >> We can't even redefine the field in our model, which would be the most >> straight forward solution, but that's not allowed by Django either. >> >> What's the correct solution for this problem? It looks to us like there >> are some unresolved issues regarding the model and migrations design. >> >> Thanks for any suggestions >> Vlastimil >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/650ed79f-7784-4eb1-91c8-60d5928b83d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations for multiple Django versions
We find out migrations with condition on Django version doesn't work. Let's have migrations based on Django version for user last_login: 1. Create database 2. Run migrations in Django 1.7 - that correctly creates table custom_user with last_login NOT NULL 3. Update Django to 1.9 4. Run migrations -> migration for auth.User is correctly ignored 5. custom_user with last_login is NOT NULL, altough it shouldn't be. Both migrations that should take care of it were ignored - our migration because it was based on Django version, auth migrations because the use is swapped. So, what now? Vlastimil Dne středa 19. října 2016 1:57:25 UTC+2 Tim Graham napsal(a): > > Assuming the problem is makemigrations generating different migrations > based on the Django version, conditionally adding operations in migrations > with some django.VERSION checks may help. > > On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote: >> >> Hi everyone, >> >> we are trying in our application to support multiple Django versions, >> specifically 1.7 to 1.9. But we encountered a problem with >> `User.last_login` field. We use custom User model based on >> `AbstractBaseUser` as specified by the documentation. Everything was fine >> in Django 1.7, but we got stuck when we wanted to add support for Django >> 1.8, where the `last_login` was modified to allow NULL values. As >> recommended by >> https://docs.djangoproject.com/en/1.10/topics/migrations/#supporting-multiple-django-versions >> >> we have migrations generated in Django 1.7 (lowest supported version) an >> thus `last_login` is NOT NULL, but that causes tests to fail when run in >> Django 1.8/1.9, since code allows `last_login` to be NULL. >> >> We can't even redefine the field in our model, which would be the most >> straight forward solution, but that's not allowed by Django either. >> >> What's the correct solution for this problem? It looks to us like there >> are some unresolved issues regarding the model and migrations design. >> >> Thanks for any suggestions >> Vlastimil >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3681c69c-c3ef-4ce3-a5b8-d6b7fcb3566b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations for multiple Django versions
I don't think separate migrations would make the problem any better, that looks just like more complicated implementation of migrations with condition in it. Our use case: Our webs consist from several projects based on Django, with dependencies between them. One of the core projects provides, among other things, custom user model for some of our applications. Given the experience we had with transition to newer Django in past we agreed to move to newer versions gradually, that is first support new version then drop the old one. Sadly there seems to be number of issues related to migrations which makes it quite hard. Personally I think, the problem lies in migrations generated for `AbstractBaseUser`. Any changes in `AbstractBaseUser` model should result in migrations for `AUTH_USER_MODEL` instead of `auth.User` model directly. That should solve the problems with migrations on custom user model. Or alternatively, let us redefine model fields inherited from parent class when we know what we're doing. IMHO warning should be enough, reporting error is not necessary. Vlastimil Dne čtvrtek 24. listopadu 2016 15:30:27 UTC+1 Tim Graham napsal(a): > > I'm not sure. Possibly you could hack up a solution with separate > migration directories for each Django version you want to support, e.g. > migrations_dj19, migrations_dj18, ... and then point to the correct > directory with settings.MIGRATION_MODULES. I'm doubtful if that can be done > elegantly when upgrading from one Django version to the next (if each > directory has different migrations) but maybe it inspires a solution. > > Off topic, but I'm curious why you want to support multiple versions of > Django with a custom user model. Usually when I see a use case for multiple > Django version support it's for reusable apps, which shouldn't contain a > custom user model. > > https://docs.djangoproject.com/en/stable/topics/auth/customizing/#reusable-apps-and-auth-user-model > > On Thursday, November 24, 2016 at 5:36:03 AM UTC-5, Vlastimil Zíma wrote: >> >> We find out migrations with condition on Django version doesn't work. >> >> Let's have migrations based on Django version for user last_login: >> 1. Create database >> 2. Run migrations in Django 1.7 - that correctly creates table >> custom_user with last_login NOT NULL >> 3. Update Django to 1.9 >> 4. Run migrations -> migration for auth.User is correctly ignored >> 5. custom_user with last_login is NOT NULL, altough it shouldn't be. >> Both migrations that should take care of it were ignored - our migration >> because it was based on Django version, auth migrations because the use is >> swapped. >> >> So, what now? >> >> Vlastimil >> >> Dne středa 19. října 2016 1:57:25 UTC+2 Tim Graham napsal(a): >>> >>> Assuming the problem is makemigrations generating different migrations >>> based on the Django version, conditionally adding operations in migrations >>> with some django.VERSION checks may help. >>> >>> On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote: >>>> >>>> Hi everyone, >>>> >>>> we are trying in our application to support multiple Django versions, >>>> specifically 1.7 to 1.9. But we encountered a problem with >>>> `User.last_login` field. We use custom User model based on >>>> `AbstractBaseUser` as specified by the documentation. Everything was fine >>>> in Django 1.7, but we got stuck when we wanted to add support for Django >>>> 1.8, where the `last_login` was modified to allow NULL values. As >>>> recommended by >>>> https://docs.djangoproject.com/en/1.10/topics/migrations/#supporting-multiple-django-versions >>>> >>>> we have migrations generated in Django 1.7 (lowest supported version) an >>>> thus `last_login` is NOT NULL, but that causes tests to fail when run in >>>> Django 1.8/1.9, since code allows `last_login` to be NULL. >>>> >>>> We can't even redefine the field in our model, which would be the most >>>> straight forward solution, but that's not allowed by Django either. >>>> >>>> What's the correct solution for this problem? It looks to us like there >>>> are some unresolved issues regarding the model and migrations design. >>>> >>>> Thanks for any suggestions >>>> Vlastimil >>>> >>> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/030257ec-f6b3-40b8-be7c-0a719c346133%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations for multiple Django versions
According the documentation, migrations should be backwards compatible, see https://docs.djangoproject.com/en/1.9/topics/migrations/#supporting-multiple-django-versions. Hence there shouldn't be any reason to make different versions of any application for different versions of Django. Also I can't quite imagine how it would be helpful - it looks like another variation on "migration based on Django version" theme. Vlastimil Dne pátek 25. listopadu 2016 11:15:55 UTC+1 Dan Tagg napsal(a): > > Hi Vlastimil, > > Why not use your source control system to publish different releases for > different versions of django. > > Dan > > On 25 November 2016 at 10:01, Vlastimil Zíma > wrote: > >> I don't think separate migrations would make the problem any better, that >> looks just like more complicated implementation of migrations with >> condition in it. >> >> Our use case: >> Our webs consist from several projects based on Django, with dependencies >> between them. One of the core projects provides, among other things, custom >> user model for some of our applications. Given the experience we had with >> transition to newer Django in past we agreed to move to newer versions >> gradually, that is first support new version then drop the old one. Sadly >> there seems to be number of issues related to migrations which makes it >> quite hard. >> >> Personally I think, the problem lies in migrations generated for >> `AbstractBaseUser`. >> Any changes in `AbstractBaseUser` model should result in migrations for >> `AUTH_USER_MODEL` instead of `auth.User` model directly. That should solve >> the problems with migrations on custom user model. >> >> Or alternatively, let us redefine model fields inherited from parent >> class when we know what we're doing. IMHO warning should be enough, >> reporting error is not necessary. >> >> Vlastimil >> >> >> Dne čtvrtek 24. listopadu 2016 15:30:27 UTC+1 Tim Graham napsal(a): >> >>> I'm not sure. Possibly you could hack up a solution with separate >>> migration directories for each Django version you want to support, e.g. >>> migrations_dj19, migrations_dj18, ... and then point to the correct >>> directory with settings.MIGRATION_MODULES. I'm doubtful if that can be done >>> elegantly when upgrading from one Django version to the next (if each >>> directory has different migrations) but maybe it inspires a solution. >>> >>> Off topic, but I'm curious why you want to support multiple versions of >>> Django with a custom user model. Usually when I see a use case for multiple >>> Django version support it's for reusable apps, which shouldn't contain a >>> custom user model. >>> >>> https://docs.djangoproject.com/en/stable/topics/auth/customizing/#reusable-apps-and-auth-user-model >>> >>> On Thursday, November 24, 2016 at 5:36:03 AM UTC-5, Vlastimil Zíma wrote: >>>> >>>> We find out migrations with condition on Django version doesn't work. >>>> >>>> Let's have migrations based on Django version for user last_login: >>>> 1. Create database >>>> 2. Run migrations in Django 1.7 - that correctly creates table >>>> custom_user with last_login NOT NULL >>>> 3. Update Django to 1.9 >>>> 4. Run migrations -> migration for auth.User is correctly ignored >>>> 5. custom_user with last_login is NOT NULL, altough it shouldn't be. >>>> Both migrations that should take care of it were ignored - our migration >>>> because it was based on Django version, auth migrations because the use is >>>> swapped. >>>> >>>> So, what now? >>>> >>>> Vlastimil >>>> >>>> Dne středa 19. října 2016 1:57:25 UTC+2 Tim Graham napsal(a): >>>>> >>>>> Assuming the problem is makemigrations generating different migrations >>>>> based on the Django version, conditionally adding operations in >>>>> migrations >>>>> with some django.VERSION checks may help. >>>>> >>>>> On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> we are trying in our application to support multiple Django versions, >>>>>> specifically 1.7 to 1.9. But we encountered a problem with >>>>>> `User.last_login` field. We use cus
