search

nshafer / django-hashid-field

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

AutoField or IntegerField #67

Closed bodgerbarnett closed 2 years ago

bodgerbarnett commented 2 years ago

This library looks like it's exactly what I need but I just have a quick question.

If I use the AutoField as a drop-in for my model's ID field, it has a few (fixable) knock-on effects where other parts of code are depending on the ID being an integer. Like, for example, creating redis tasks.

I'm using rest-framework so I'm thinking it might be better for me to use the standard IntegerField from this library in a separate field which can be serialized instead of my existing ID field. That would (obviously) require me to create a data migration for my existing rows which is fine but I think it would also require me to ensure that any new rows that are created have this new field initialised.

Does that sound sensible to you? Or is dropping in the AutoField on top of the ID a better way to do it?

nshafer commented 2 years ago

This module is drop-in only in the sense that it doesn't modify the records in the database. It will still change how other code interacts with the field. Most of the time it's fine, because most code that is duck-typed and doesn't actually check the type of the field will just work regardless of whether it's an int, str or hashid_field.Hashid. However, if you have code that is definitely checking on the types, then this module is not drop-in in that sense. I have some plans to allow that kind of drop-in replacement that I've started working towards in the last couple releases, but I still need to figure out some things and do some work on it. In the meantime, you could create another field and copy the data on save(), or https://pypi.org/project/django-hashids/ might work better for your use-case.

bodgerbarnett commented 2 years ago

Ah, I see. Thanks for the prompt and clear response! I'll use django-hashids for my project, I think.