Change how menu items relate to orders and order items

Whilst we're already on the topic of drastically changing the database:

As it stands, rows in the OrderItem table (e.g. 1x hamburger (no onion) belonging to order no. 23) contains a menu attribute, which is a foreign key pointing to an entry in the MenuItem table instead of it being just a string with the name of the menu items.

This was chosen, IIRC, primarily to reduce the size of the order items table as it would without a doubt be the fastest growing table. It would also make changing menu items cleaner, provide some kind of consistency to keeping statistics (use the same hamburger menu item for several events etc), and make compiling statistics a lot easier, since there'd be no need to match strings.

This choice came with a following design choice to make, however, namely what should happen if a menu item is deleted? Should we:

1. Delete the OrderItem row completely (as it is done now)?

Easy and clean, but deletes data from long-term statistics if users don't use the active attribute of a menu item enough. The current implementation of the menu item foreign key also means that empty orders can and do exist, since we don't periodically check the database for empty orders.

2. Set the OrderItem's menu attribute to NULL?

Also very easy and clean, but might ruin long-term statistics (it will count and display what quantity of Undefined has been ordered). Might preserve an indication of what type of menu item it was, since a row would change to 1x Undefined (no onion) to order no. 23. Also means we would have to allow the foreign key to be nullable, which would mean we could potentially create empty order item rows from the get-go.

Both these two alternatives also raise the question of whether or not we event want to save orders that are either empty or full of undefined items, or should just remove everything. What do we do with orders that contain 1x hamburger and 1x undefined?

3. Set the value to a default menu item of ID 0?

Essentially the same solution as no. 2, but without having to deal with NULL and setting the attribute to nullable.

4. DGAF about using foreign keys and instead save the respective menu item's name attribute as a string?

Would also probably be quite easy to implement using a get_name-function. Would preserve orders in the database better over time, but is this even something we want or should we put that responsibility on the users instead? Would also mean a larger table byte-size and would make comparing a little bit more annoying with string literals instead of matching numerical ID:s.

Perhaps we could discuss this a bit after the vacations? @dakaza98

class OrderItem(models.Model):
    id = models.AutoField(primary_key=True)
    menu = models.ForeignKey(
        to=MenuItem,
        on_delete=models.CASCADE,
        verbose_name=_('menu item'),
        help_text=_('Which item that was ordered.'),
    )

UTNkar / ordsys