We've had some various requests which have boiled down to users needing to store extra data against Hordak models. Right now we just suggest users create their own model with a one-to-one relationship to the Hordak model. But it is worth considering other options.
Option 1: Allow extending the models
This is the same approach as Django's auth system, i.e. USER_MODEL=..., then calling get_user_model() in your code. This gives the maximal flexibility, but I don't like it because:
Pro: Maximal flexibility
Con: It makes all the Hordak code much messier
Con: Database table names now need to be dynamically determined (which will be a huge pain for our in-db code)
Con: It's probably not a walk in the park from the user's point of view too.
Option 2: Provide each model with an extensible field
Here we provide each model with a flexible field for extra data. For example, a JSONField called extra. I like this for its simplicity.
Con: No schema
Pro: Easy to implement
Pro: Conceptually simple
I also think we could provide some quality-of-life settings around this data. For example, we could provide settings that allow users to add keys in the extra field to the admin filtering UI or search box. Plus users would still be free to create indexes as they desire in their own migrations.
Option 3: One-to-one relationships (the status quo)
We've had some various requests which have boiled down to users needing to store extra data against Hordak models. Right now we just suggest users create their own model with a one-to-one relationship to the Hordak model. But it is worth considering other options.
Option 1: Allow extending the models
This is the same approach as Django's auth system, i.e.
USER_MODEL=..., then callingget_user_model()in your code. This gives the maximal flexibility, but I don't like it because:Option 2: Provide each model with an extensible field
Here we provide each model with a flexible field for extra data. For example, a
JSONFieldcalledextra. I like this for its simplicity.I also think we could provide some quality-of-life settings around this data. For example, we could provide settings that allow users to add keys in the
extrafield to the admin filtering UI or search box. Plus users would still be free to create indexes as they desire in their own migrations.Option 3: One-to-one relationships (the status quo)
(ran out of time, got to go for now)