Do we allow some kind of model customisation?

[adamcharnock]

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)

Users create their own model with a one-to-one relationship to the Hordak model.

• Con: An extra join
• Con: Requires definition of another model
• Pro: Has schema, and so can be migrated
• Pro: Makes better use of the ORM's features (no one wants to put a foreign key in a JSON blob)

Current thinking

I've come back to this issue as it is relevant to a project I am working on now. As a user of Hordak, option 3 seems to be actually the most appealing. I may give it a go and see if I run into any issues. I've just updated my current project to use option 3 and it was much much better than the previous JSON-based approach (I was putting JSON in the Leg.description field as a temporary hack).

I'm therefore leaning heavily towards maintaining the status quo of option 3

[nitsujri]

Vote goes to Option 3.

We basically do Option 3 with a hordak_source.TransactionSource that joins hordak.models.Transaction to other objects so we have a hard link on what generated a specific transaction/leg-set.

Thoughts Against Option 1

1. Most difficult to maintain especially considering the DB triggers which is a layer beyond the simple get_user_model().
2. It's not just "Hordak Model" but it's which model of Leg, Account, Transaction does the end user want to change? All 3 would need to be maintained as get_<model>_model().
3. Unlike User, what fundamental aspect of those 3 models do they need to change? The point of using your own User is to change logins from username to email, or change from first_name/last_name to name. There really isn't something applications need to fundamentally change. They all simply want to "extend". (I can agree maybe we're missing some helper functions like pos/neg Leg based on Account type, but that's not fundamental). So, monkey patch!

Long winded to say - I agree =)