seawolf42 / django-lookup-tables Goto Github PK

There should be a built-in validator for fields.LookupTableItemField that confirms the item being related to is actually of the correct type prior to saving.

Learned the pattern being used for lookup tables is an anti-pattern; this needs to be re-architected to use a new approach:

• abstract base class that all lookup tables can derive from
• continue to provide the model field to ensure things like on_delete are implemented consistently in the app and to continue to provide correct choices logic
• alter the Django REST Framework field to continue to provide the choices logic

The field should honor the default='xxx' parameter just like a CharField does; if present, and if no value is provided for the field, it should set itself to the LookupTableItem having this value. If that item does not exist, it should be created.

If a default is provided and the table is being created, the item named <DEFAULT> that is auto-created should instead be named the value of the default parameter.

I think the right way for a model to reference a lookup table and the selected item in that table is to use a custom ModelField implementation. The field will contain a foreign key to the LookupTableItem and the field definition will include a parameter that maps the field to a specific LookupTable instance (which determines which items can be selected).

It would be very convenient if a user could use the field like this:

class MyModel(models.Model):
    lookup = LookupTableItemField(table_ref='abc')

instance = MyModel.objects.get(pk=some_pk)
instance.lookup = 'the name of an option'
instance.save()

This requires marshaling the field to find the right LookupTableItem for that value. If no such item exists, this should be an error.

Lookup tables are separate tables, but they should be administered as if they were all a common thing, with a single admin entry point (/admin/lookuptable/?) that gives a list of all tables, and clicking on a table lets you manage the list of items for that table.

Sometimes drop-downs are enough to annotate a model, but the data associated with the drop-down should include additional metadata that can be adjusted to annotate values. For instance, a time tracking tool line item might have a type that includes the following choices:

1. Research
2. Dev
3. QA

'Dev' and 'QA' might be both billable to a client, where 'Research' is not.

The django-rest-framework serializer field specified in drf_fields.py currently requires the user specify a table for the lookup, and if the model field is optional the user must also provide allow_null=True and required=False on the serializer field. This should be determined automatically by inspecting the model field.

There should be a simple way for consumers to:

• look up a LookupTable instance and retrieve all values for that table
• add/remove/edit/reorder values for a table

The default permission class should probably be is_staff to manage table values and any to read values, so rest_framework.permissions.IsStaffOrReadOnly.

Right now the .lookuptable property is lazy-loaded to prevent Django model queries to the DBMS prior to Django being fully-loaded. The implementation is trivial but:

• contains a race condition (probably not an issue in real-world, but inelegant)
• requires a property check on every method call to .get_lookuptableitem_choices()

This should be replaced with something more pythonic.