API and entity to store radio station administration

Parent: [EPIC] Basic radio station administration (aura#221 - closed)

See parent.

changed milestone to %1.0-alpha3 — Playful Platypus

added discuss + 1 deleted label

assigned to @eigenwijsje

mentioned in issue aura#221 (closed)

@eigenwijsje @kmohrf I'm not totally sure, if some rigid database structure is the right approach to store settings. Especially considering this will grow a lot overtime and be consumed by clients most likely in a "all or nothing" manner (compare the last paragraph in the ticket description above).

At least the API response should probably a single JSON map, holding all settings at once.

So I'd be thankful if you both could do some exchange, on some future-proof approach and decide for yourself. Konrad, I'm thinking about your personal experience with the Tekno PWA and how you would design such global settings container API.

Some time ago, I've created Provide a `Settings` entity with key, value pairs (#121 - closed) which got kicked down GitLab abyss (also see this comment), which resembles some thought, when going some more dynamic route.

marked this issue as related to #121 (closed)

added To Do label

If the API should only support reading all the values at once, as JSON, then we can add them as settings, and expose them through a view.

Alternatively, we could put all these settings in a JSON file and just serve it. I would advice against this, because it splits the settings to two locations.

But, if the API should also support creating, updating and deleting, then we will need a model.

I'd also vote for storing settings in the database. And yes, they need to be written too.

The only question left, how we structure the model: more hard-wired (table for each config options; seems not so sensible to me) vs. dynamic (like a key-value store plus JSON schema validations on the values for example).

added P1 label

I have a simple prototype with django-polymorphic and django-rest-polymorphic that can handle integer and string settings and provide a single endpoint for both.

It can be expanded to handle text areas and probable lists of URLs.

added Blocked label and removed To Do label

removed discuss label

added discuss label

added 1 deleted label

added Doing label and removed Blocked label

It turns out that both packages are not officially supporting the latest Django version and seem more or less unmaintained.

The last version from django-polymorphic is from November 2021, and the last django-rest-polymorphic version is from July 2022.

Anyway, the polymorphic-settings branch has support for image, integer and text settings.

The response is rather verbose, but I think that is the price for making it polymorphic.

$ http -p b GET :8000/api/v1/settings/

[
    {
        "key": "LOGO",
        "type": "imagesettings",
        "value": "http://localhost:8000/site_media/images/radio_helsinki_square_colour_QXgJ0GC.jpg"
    },
    {
        "key": "SHOW_ID",
        "type": "integersettings",
        "value": 926
    },
    {
        "key": "NAME",
        "type": "textsettings",
        "value": "Radio Helsinki"
    },
    {
        "key": "PLAYLIST_ID",
        "type": "integersettings",
        "value": 2357
    }
]

removed Doing label

@fm_margarethem , @david and @kmohrf: If this is usable for the dashboard, we can expand the types if needed.

added Blocked label

I experimented further with simply storing the settings as JSON file.

The json-settings branch is much simpler than using the database.

I would prefer this solution better.