id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 6280 IntegerField member_name and PositiveIntegerField error bo@… nobody "Using raw_id_admin = True On a ForeignKey that is references to a PostitiveIntegerField causes a {{{ __init__() got an unexpected keyword argument 'member_name' on python2.5/django/utils/maxlength.py in inner, line 47 }}} i.e. {{{ --- Failure when editing Provider --- class User(models.Model): uid = models.PositiveIntegerField(primary_key=True) login = models.CharField(max_length=150) class Provider(models.Model): provider_id = models.PositiveIntegerField(primary_key = True) user = models.ForeignKey(User, db_column = 'uid', raw_id_admin = True) --- Failure when editing Provider --- --- OK editing Provider --- class User(models.Model): uid = models.IntegerField(primary_key=True) login = models.CharField(max_length=150) class Provider(models.Model): provider_id = models.PositiveIntegerField(primary_key = True) user = models.ForeignKey(User, db_column = 'uid', raw_id_admin = True) --- OK editing Provider --- }}} Seems strange as most DB 'default' Primary Keys are in-fact PostitiveIntegerFields This little issue crops up often when inspection of the DB for migration. Its not really a bug per-say. Its just the optimal validator for 'raw_id_admin' should check for the ID < 0 case before asking the DB if such an ID exists. And of course to take advantage of the UNSIGNED/indexing optimizations DB's have for such fields if one were to ""syncdb"" (which bears itself out when the dataset is huge) " closed contrib.admin 0.96 fixed member_name PostitiveIntegerField Accepted 0 0 0 0 0 0