Skip to content

wip: non-integer primary keys#279

Draft
knokko wants to merge 3 commits into
masterfrom
non-integer-ids
Draft

wip: non-integer primary keys#279
knokko wants to merge 3 commits into
masterfrom
non-integer-ids

Conversation

@knokko
Copy link
Copy Markdown

@knokko knokko commented May 7, 2026

This PR improves support for non-integer primary keys

Currently, binder sort of allows it, but:

  • You cannot invoke detail endpoints
  • You cannot invoke detail routes
  • The name of the primary key field is always sent as id over the network,
    regardless of what the name of the primary key field is.
  • Any relations will fail miserably because binder accepts only integer IDs.

This PR fixes all of these shortcomings.
Furthermore, it fixes some history changeset inconsistencies.

knokko added 2 commits May 8, 2026 12:22
This commit dramatically improves the way binder handles non-integer primary keys.

Currently, binder sort of allows it, but:
- You cannot invoke detail endpoints
- You cannot invoke detail routes
- The name of the primary key field is always sent as `id` over the network,
regardless of what the name of the primary key field is.
- Any relations will fail miserably because binder accepts only integer IDs.

This commit fixes all of these shortcomings.
@knokko knokko force-pushed the non-integer-ids branch from 3871f4e to cce13d7 Compare May 8, 2026 10:26
@BBooijLiewes BBooijLiewes self-requested a review May 8, 2026 13:13
@knokko
Copy link
Copy Markdown
Author

knokko commented May 8, 2026

Note that filtering on foreign key is now handled by this code:

# For foreign keys and similar fields, we should use the filter of the primary key of the related object
class_for_filtering = field.__class__
if isinstance(field, models.ForeignObject) or isinstance(field, models.ManyToManyField) or isinstance(field, models.ForeignObjectRel):
	class_for_filtering = field.related_model._meta.pk.__class__

Prior to this PR, it was hardcoded as part of IntegerField.

Before updating django-hijack, the /user/endmasquerade/ endpoint would yield 200 when it succeeds,
and yield 403 when it fails because the user is not masquerated.

After updating django-hijack, it would always yield 200.

This commit restores the old behavior of returning 403 for non-masquerated users.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant