1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note
I was just writing some code against 1.5 and thought I might use the new .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which is an MVCC... which re-writes the entire row as far as I know even when one column is being updated. I popped into the release notes and it does in fact indicate that it is useful for high concurrency scenarios. I thought it would be nice to note in the docs somewhere that it is really not useful for database of this type unless you are using a healthy amount of the update_fields elsewhere. I might be wrong on all of this. I have never made a documentation change nor have any idea what the process would be so if someone chooses to make this note, please do! Thanks everyone! Christian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/LIGJJ2qwBZgJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note
Exactly... I guess I was just asking for someone to say 'Don't use this if you think it will make the update any faster on Postgres' in the docs... in addition to what you just said :) On Fri, Nov 2, 2012 at 7:45 PM, Donald Stufft wrote: > The major help is preventing clobbering a value for concurrency. > > Prior to this when you loaded an object from SQL into a django model, it > would fetch all the values > as they were at that time, and store them in the model instance. Then when > you saved it it would > write all those values back out to the database, even if someone else had > changed them and > you didn't. > > Now if you fetch a particular instance, and make a change, you can save > only that value, and you > won't clobber other peoples saves if they made a change to an unrelated > field on that row. > > On Friday, November 2, 2012 at 9:42 PM, Christian Jensen wrote: > > I was just writing some code against 1.5 and thought I might use the new > .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which > is an MVCC... which re-writes the entire row as far as I know even when one > column is being updated. > > I popped into the release notes and it does in fact indicate that it is > useful for high concurrency scenarios. > > I thought it would be nice to note in the docs somewhere that it is really > not useful for database of this type unless you are using a healthy amount > of the update_fields elsewhere. > > I might be wrong on all of this. > > I have never made a documentation change nor have any idea what the > process would be so if someone chooses to make this note, please do! > > Thanks everyone! > Christian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/LIGJJ2qwBZgJ. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- *Christian Jensen* 724 Ioco Rd Port Moody, BC V3H 2W8 +1 (778) 996-4283 christ...@jensenbox.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Custom user models in 1.5, not flexible/dry enough?
I think this is the right approach when I was making my custom user model I was thinking the same thing. I hope these mixins make it in. Sent from my iPhone On 2012-11-06, at 2:55 PM, Alex Ogier wrote: So, I went ahead and implemented the most useful mixin of the three that I defined previously, the PermissionsMixin. You can see it at https://github.com/ogier/django/blob/permissions-mixin/django/contrib/auth/models.py#L293 This should dramatically simplify the creation of a custom User model in the case that you are OK with Django's default permissions model (and I think many people are). Now instead of reimplementing dumbed-down versions of the permissions code whenever you want to use admin, you can just add PermissionsMixin to your parent classes and *poof* your user model is compatible with contrib.admin (though you still need to roll your own admin class, maybe we can help here too). This would DRY up some of https://docs.djangoproject.com/en/1.5/topics/auth/#a-full-example which could forget about permission-handling code, and still have fully-fledged app permissions. I think this covers 80% of what is missing from the current class hierarchy. Forcing every AbstractBaseUser to have a password isn't strictly required, but seeing as Django's implementation is pretty good and we don't want to encourage people to go rolling their own, it seems like an OK limitation. Forms will still have to be overridden, but that was always inevitable. On Tue, Nov 6, 2012 at 5:02 PM, Anssi Kääriäinen wrote: > On 6 marras, 23:05, Alex Ogier wrote: > > > ... Since you can't actually override or change the fields of an > abstract model anyways (so far as I know?) > > Allowing override of abstract parent's fields is fairly trivial > (https://github.com/akaariai/django/compare/abstract_overrides). > > I don't immediately see a reason to disallow override of abstract > parent's fields. > > Anyways it seems there is some room for improvement in model > validation for abstract parent case: > > class Foo(models.Model): > username = models.CharField(max_length=100) > > class Meta: > abstract = True > > class FooOverride(models.Model): > username = models.CharField(max_length=200) > > class Meta: > abstract = True > > class Bar(Foo, FooOverride): > pass > > print(Bar._meta.fields) > [, > , > ] > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Perimission field name on the new Custom User Model
I was tweaking around with making an email address only User model (sans username) while still retaining the permissions stuff and ran into a small issue. I can fix it but it might need to be documented. Here is the problem: I copied over the entire AbstractUser of django.contrib.auth.models.py, made my changes I needed and just for fun changed 'user_permissions' to just 'permissions' because I liked the name in the database to be 'account_user_permissions' instead of 'account_user_user_permissions' When I went to run it, line 44 of ModelBackend died because there is a hard reference to 'user_permissions' in the line: user_obj._perm_cache = set(["%s.%s" % (p.content_type.app_label, p.codename) for p in user_obj.*user_permissions*.select_related()]) The only fix I could come up with quickly was to copy out the entire ModelBackend and fix it there. I am probably an idiot and just not know the better way to fix this. Christian -- *Christian Jensen* 724 Ioco Rd Port Moody, BC V3H 2W8 +1 (778) 996-4283 christ...@jensenbox.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Perimission field name on the new Custom User Model
Yea, the column name was the first thing I tried - it had no effect on the name of the database table that was created. I am good with copying the entire ModelBackend I just thought someone would either want to document this fact or make it configurable. Christian On Thu, Nov 8, 2012 at 1:22 PM, Alex Ogier wrote: > Django's permission system does expect there to be a user_permissions > property on user objects. It's possible to change django to refer to that > field indirectly, in the same way that it refers to > CustomUser.USERNAME_FIELD, but Django core developers would be unlikely to > accept the change because this is a rare use case. Instead, if you want to > clean up the database field names, I would try adding a > db_column="permissions" argument to the user_permissions field declaration > in your custom user model. That should change the database field name > without interfering with Django's ModelBackend. > > Best, > Alex Ogier > > > On Thu, Nov 8, 2012 at 3:27 PM, Christian Jensen > wrote: > >> I was tweaking around with making an email address only User model (sans >> username) while still retaining the permissions stuff and ran into a small >> issue. I can fix it but it might need to be documented. >> >> Here is the problem: >> >> I copied over the entire AbstractUser of django.contrib.auth.models.py, >> made my changes I needed and just for fun changed 'user_permissions' to >> just 'permissions' because I liked the name in the database to be >> 'account_user_permissions' instead of 'account_user_user_permissions' >> >> When I went to run it, line 44 of ModelBackend died because there is a >> hard reference to 'user_permissions' in the line: >> >> user_obj._perm_cache = set(["%s.%s" % (p.content_type.app_label, >> p.codename) for p in user_obj.*user_permissions*.select_related()]) >> >> The only fix I could come up with quickly was to copy out the entire >> ModelBackend and fix it there. I am probably an idiot and just not know the >> better way to fix this. >> >> >> Christian >> -- >> >> *Christian Jensen* >> 724 Ioco Rd >> Port Moody, BC V3H 2W8 >> +1 (778) 996-4283 >> christ...@jensenbox.com >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- *Christian Jensen* 724 Ioco Rd Port Moody, BC V3H 2W8 +1 (778) 996-4283 christ...@jensenbox.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
dumpdata with custom auth model
Hi, Has anyone run into an issue where dumpdata refers to the old auth model and tries to dump its data? Here is what I am encountering: DEBUG 2012-11-09 11:49:46,363 util 8457 140488053692160 (0.002) SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."is_superuser", "auth_user"."date_joined" FROM "auth_user" ORDER BY "auth_user"."id" ASC; args=() CommandError: Unable to serialize database: relation "auth_user" does not exist LINE 1: ...r"."is_superuser", "auth_user"."date_joined" FROM "auth_user... -- *Christian Jensen* 724 Ioco Rd Port Moody, BC V3H 2W8 +1 (778) 996-4283 christ...@jensenbox.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
