[Feature Request] SpicyField that leverages the GeneratedField
VaZark opened this issue · comments
In Django 5, we have the GeneratedField that allows you to use virtual/generated columns based on other fields of a record. It would great with we can have a field that leverages that instead of directly modifying the id itself. This way we can leverage drf and other third-party libs to target the virtual field and avoid the finicky middleware in the URL declaration.
Maybe the field definition can directly contain the decryption logic and point to the ID field when used with queries while acting as a non-editable charfield otherwise ?
Hi @VaZark!
If I understand correctly, your idea would be to build a GeneratedField that points to a normal PrimaryKey, and returns the "spicy" (stringified) value.
That seems possible, but it's a very different design. The goal of this library is to be able to act as a Model's primary key field in place, and without making changes to callers. In other words, every place that already uses instance.pk or instance.id needs to Just Work. In your proposal, callers would need to be aware of that other field.
avoid the finicky middleware in the URL declaration
Which part is that? I don't think we include a middleware, but maybe you're talking about the register_converter part. Unfortunately that's just the way custom field types work in Django (haven't found a way to reduce this boilerplate), but, it's been working well for us in production.
That's exactly it.
Callers would need to be aware of that other field.
Kinda.... The onus is now on the devs. So we have the flexibility to choose to expose or not to expose it or even use it both in conjunction with different apps.
To me, the coolest part would be having multiple generated spicy IDs for a single entry. We can have different spicy_id per service when working with different services. For example, the warehouse does not need to know this is for customer_XXXX or invoice_XXXX. All they need to know is the delivery is associated with delivery_XXXX.
Kinda.... The onus is now on the devs. So we have the flexibility to choose to expose or not to expose it or even use it both in conjunction with different apps.
Gotcha! So that's definitely a different design goal; it isn't the "drop in replacement" goal here. It does sound like you could borrow some concepts (or code) and make it happen as a plain old GeneratedField, either local to your project or in your own library.
I don't see a feature to add here, but by all means give something a shot on your own!