Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for TextField pk #46

Closed
arshsingh opened this issue Apr 30, 2020 · 2 comments
Closed

Add support for TextField pk #46

arshsingh opened this issue Apr 30, 2020 · 2 comments

Comments

@arshsingh
Copy link

I use a TextField pk, specifically https://github.com/ergeon/python-flax-id

@aaugustin
Copy link
Owner

Let's discuss adding support for CharField, which flax-id uses.

TextField is essentially "CharField so large that I don't want to bother specifying a max_length. I expect a PK to have constant length so I'm not sure it makes sense to support TextField` here. Let's wait for someone to actually need it.

Coming back to CharField, the question is "how to encode it in the sesame token".

Currently django-sesame is able to encode / decode integers and UUID, which are fixed length — 4 bytes and 16 bytes respectively. The token format is designed to be as compact as possible (because long URLs are ugly, get truncated accidentally, etc.) So django-sesame just reads the expected number of bytes from the token. There's nothing else.

Since strings are variable length, the most generic format would be 1 byte for the length of the UTF-8 encoded string, followed by the UTF-8 encoded string. (Supporting only up to 255 characters would be an acceptable limitation for an user id that ends up in a URL.)

This wouldn't be optimal for flax-id, though:

  • IDs are fixed length, so there's no need for the length byte
  • It would be best to use IDs in the "12 bytes" form rather than in the "16 URL-safe characters" form because django-sesame always base64-encodes the whole token to make it URL-safe, and there's no point doing it twice

There's no way django-sesame can determine and handle all this, so the only way to allow these optimizations is to make the packer configurable.


To sum up:

  1. I'd like to support custom packers in addition to the three natively supported packers — then you can do the optimal thing for flax-id if you want
  2. I'm unsure about adding a CharField packer (and BinaryField, which would be the same, minus the UTF-8 encoding). As shown above, the generic implementation is unlikely to be the best implementation in most cases. Most users certainly care a lot more about having something that works and a lot less about having something optimal than I do...

aaugustin added a commit that referenced this issue May 10, 2020
@arshsingh
Copy link
Author

This is great! Thank you 🌟

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants