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