nshafer / django-hashid-field

Django Model Field that uses Hashids to obscure the value
MIT License
370 stars 40 forks source link

Add ability to have a per-model prefix #21

Closed PawelDecowski closed 3 years ago

PawelDecowski commented 6 years ago

It would be nice to be able to specify a per-model prefix, eg:

class User(models.Model)
    id = AutoHashId(primary_key=True, prefix='us_')
    # ids like us_3n3b3hjbjh4

class Project(models.Mode)
    id =  AutoHashId(primary_key=True, prefix='pr_')
    # ids like pr_j5f7l3hg5k5l
nshafer commented 6 years ago

Not a bad idea, and you're not the only one to think of it. I just found @pegler has created a fork with that functionality. I'll review his work.

pegler commented 6 years ago

Cool. We've been using my fork for a few weeks developing a new API. There are two features on that fork, so if you only want prefix support, we'll need to clean it up a bit.

The other is a new proxy field thats let you, for example, have both an id and hash_id fields, where hash_id only accepts and returns hashids and is a virtual/proxy field andid still functions like before. We needed this to support legacy systems that only lookup by integer ID, while we want some new systems to only look up by hashid. HASHID_FIELD_ALLOW_INT_LOOKUP wouldn't work because it would allow the new systems to look up by hashid or int, which was not acceptable.

nshafer commented 6 years ago

Ahh, interesting. I'll have to take a look when I get a chance.

bjmc commented 3 years ago

I'd be very interested in this feature. We'd like to prefix our IDs with a tag URI scheme to produce globally-unique identifiers.

Would the maintainers be interested in accepting a PR?

nshafer commented 3 years ago

Added in 3.2, thanks @bjmc

bjmc commented 3 years ago

Hi @nshafer thanks for accepting my MR! Can I ask you to hold off on making a release for a week or so? I actually think what I've done could stand some improvement. I think it might be better if the prefix callable executed in the context of the descriptor when it's accessed, instead of at model-definition time when the field is associated with the model.

nshafer commented 3 years ago

OK, I have just removed the callable support for now so that it doesn't hold up a new release. I did think it was a little superfluous since it's called in pretty much the same context as just setting the string, but I figured there was a use-case I wasn't aware of or thinking of. I'll take another PR once it's more defined.