Re: Declarative mechanism for Django model rows

Check out fixtures:

https://docs.djangoproject.com/en/3.2/howto/initial-data/

On December 8, 2021 1:25:45 PM CST, Alex Dehnert <adehnert@mit.edu> wrote:

With some frequency, I end up with models who contents are approximately 
constant. Are there good ways of handling this?

For example, I might have a set of plans that users can sign up 
for, with various attributes -- ID, name, order in the list of plans, 
cost, whether the purchaser needs to be a student/FOSS project/etc.. I'm 
going to rarely add/remove/change rows, and when I do there's likely going 
to be code changes too (eg, to change landing pages), so I'd like the 
contents of the model (not just the schema) to be managed in the code 
rather than through the Django admin (and consequently use pull requests 
to manage them, make sure test deploys are in sync, etc.). I'd also like 
it to be in the database, though, so I can select them using any column of 
the model, filter for things like "show me any project owned by a paid 
account", etc..

I think my ideal would be something like "have a list of model instances 
in my code, and either Django's ORM magically pretends they're actually in 
the database, or makemigrations makes data migrations for me", but I don't 
think that exists?

The two workable approaches that come to mind are to either write data 
migrations by hand or use regular classes (or dicts) and write whatever 
getters and filters I actually want by hand.

Data migrations give me all the Django ORM functionality I might want, but 
any time I change a row I need to write a migration by hand, and figuring 
out the actual state involves either looking in the Django admin or 
looking through all the data migrations to figure out their combined 
impact. (Oh, and if somebody accidentally deletes the objects in the 
database (most likely on a test install...) or a migration is screwy 
recovering will be a mess.)

Just using non-ORM classes in the source is a clearer, more declarative 
approach, but I need to add replacements for many things I might normally 
do in the ORM (.objects.get(...), __plan__is_student, 
.values(plan__is_student).annotate(...), etc.).

Which of these approaches is better presumably depends on how much ORM 
functionality I actually want and how often I expect to be changing 
things.

Are there other good approaches for this? Am I missing some Django feature 
(or add-on) that makes this easier?

Thanks,
Alex

P.S. I previously asked this on StackOverflow at 
https://stackoverflow.com/questions/70204467/declarative-mechanism-for-django-model-rows, 
but I'm realising this list is probably better.

-- 
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/alpine.DEB.2.21.2112081409120.12786%40novgorod.mit.edu.