Re: Declarative mechanism for Django model rows
Hello, Am 08.12.21 um 20:25 schrieb Alex Dehnert: > With some frequency, I end up with models who contents are approximately > constant. Are there good ways of handling this? If I understand your question correctly, you have a model that you always query like: plans = Plan.objects.all() and that is changed so infrequently that `plans` could be a read-only global, updated only on the rare ocassions it is changed in Admin (or shell etc.)? This would require to properly encapsulate the writes to the global, about which I too (if this covers your question) would be interested in getting help. Best regards, Carsten -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d5c949b7-b6a9-e2bb-b021-eca8786d68d9%40cafu.de.
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 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55D126DC-6D7A-42EE-A482-423C214E7677%40fattuba.com.
Re: Declarative mechanism for Django model rows
I may be completely misunderstanding your use case, but just in case… You can have different views in your application, and if you don’t want to expose the data as separate pages then you might consider django-rest-framework to provide data in various ways, including across models. You’ll end up doing a bit of javascript but not have to dive back into your database for changes in how you want things to be accessed. Flexible searches on attributes might be best supported by folding in ElasticSearch or something similar. It might seem like a heavy addition to a small-ish application, but once it it running it is flexible and trouble-free. hth - Tom > On Dec 8, 2021, at 11:25 AM, Alex Dehnert 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ADF2C45E-6CFD-469C-8B11-F61056D67853%40gmail.com.
Declarative mechanism for Django model rows
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+unsubscr...@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.
