Generic relations and non-integer primary keys

[Rudolph]

The documentation for Generic Relations uses a PositiveIntegerField
for the "object-id". However some models might have a non-integer
field as a primary key, so it might be good to add a note to the
documentation that a different field type is needed if one of your
models uses a non-integer primary key.

Shall I add a ticket for this and add a patch for the documentation to
include such a remark?

Thanks!

Rudolph

[Luke Plant]

On Wednesday 16 July 2008 09:13:21 Rudolph wrote:
> The documentation for Generic Relations uses a PositiveIntegerField
> for the "object-id". However some models might have a non-integer
> field as a primary key, so it might be good to add a note to the
> documentation that a different field type is needed if one of your
> models uses a non-integer primary key.

Surely the problem is much bigger than just changing the field type?
In general, you are going to need a varchar or something, and then
you will need a way of mapping between your primary key values and
the value stored in the object-id field. But in order for the
GenericForeignKey queries to work it will need to know about this
mapping.

The GenericForeignKey stuff actually comes in part from one of my own
projects, and I have this case of non-integer primary keys. In order
to handle it, I have to register 'mappers' for every model that the
GenericForeignKey handles. It's a bit messy, and not at all
compatible with the GenericForeignKey in Django.

Basically, the GenericRelation stuff can't be used with models that
don't have integer primary keys without rewriting parts of it AFAICS.

Luke

--
"Mediocrity: It takes a lot less time, and most people don't realise
until it's too late." (despair.com)

Luke Plant || http://lukeplant.me.uk/

[Malcolm Tredinnick]

On Wed, 2008-07-16 at 01:13 -0700, Rudolph wrote:
> The documentation for Generic Relations uses a PositiveIntegerField
> for the "object-id". However some models might have a non-integer
> field as a primary key, so it might be good to add a note to the
> documentation that a different field type is needed if one of your
> models uses a non-integer primary key.

True. That's pretty much unavoidable, too. Handling arbitrary content
types is way too complex to be worth it. I've put a fair bit of thought
into the possibilities there because it crops up in a few disguises,
but it's a briar patch full of trouble.

> Shall I add a ticket for this and add a patch for the documentation to
> include such a remark?

Well, that depends. Would you like the problem to be fixed or not? :-)

Malcolm

[Rudolph]

> Well, that depends. Would you like the problem to be fixed or not? :-)
>
> Malcolm

I can imagine that it will be complex to fix (lot's of field types). A
note in the docs would be nice since an integer primary key is a
requirement for generic relations. I've opened a ticket that adds this
requirement to the docs:
http://code.djangoproject.com/ticket/7785

Rudolph

[Tai Lee]

A documentation change about using a different field type is not
enough in some cases (PostgreSQL 8.3), as noted in #6523 [1].
PostgreSQL 8.3 won't implicitly cast variables anymore, so if you pick
integer for your generic relation you'll have problems relating models
with varchar, and vice versa. Can't have it both ways, it seems.

[1] http://code.djangoproject.com/ticket/6523

[Rudolph]

Yes, that's why the proposed patch for the documentation says that
both must be of the same type:
http://code.djangoproject.com/attachment/ticket/7785/note-about-primary-keys.diff

Rudolph