Check out fixtures: https://docs.djangoproject.com/en/3.2/howto/initial-data/
On December 8, 2021 1:25:45 PM CST, Alex Dehnert <[email protected]> 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 [email protected]. >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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55D126DC-6D7A-42EE-A482-423C214E7677%40fattuba.com.
