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