Database backend that stores semantic data (locales as a table, versions as a table, etc.)

[Osmose]

It's a rather common need to want to use the list of locales in product_details as the choices for a locale field (let's call this a LocaleField). Less common but still useful would be a similar thing for versions. There are problems around this:

• If you generate migrations for a model without up-to-date product_details, the migration will alter the field unnecessarily.
• It requires a product_details update (and an internet connection) or checked-in product_details files for setup (or a finnicky fallback for when product_details is missing).
• If using the database-based product_details, test database setup needs to be customized.

I propose that the database backend should have a locales table and a version table, and models wanting to have a LocaleField can have a ForeignKey to the product_details tables. I think this would avoid all the weirdness around choices.

[pmclanahan]

Interesting. One thing I'll point out is that there is already product-details data (up-to-date as of the date of library version release) included in the package on PyPI. There is also a migration that will pre-load your DB table with said data so that you don't need an internet connection. I'd also recommend against using database-based product_details during test runs. The default config has the aforementioned data already.

We could provide a LocaleField class that has that all setup w/o need of a different DB schema, and that would work regardless of the data storage backend. I feel like denying the use of such a field to projects that don't want or need the product_details data in the DB isn't a good thing. I could be convinced otherwise though if others need this.