OK, thanks a lot for that. I have only just started using Django and, for that matter, Python. It's really valuable to gain a bit of insight into how the more experienced might tackle the issues I am facing.
Thanks again for the suggestions, Rob On Feb 16, 11:47 pm, Alex Gaynor <[email protected]> wrote: > On Mon, Feb 16, 2009 at 6:29 PM, Russell Keith-Magee <[email protected] > > > > > wrote: > > > On Tue, Feb 17, 2009 at 6:24 AM, Rob <[email protected]> wrote: > > > > I'm writing a Django app to act as the front-end interface to a backup > > > application, using MySQL as the database. I need to store some > > > variables to act as the "global" settings specific to my app - like > > > UNIX backup location, etc. > > > > At present I have a model called Setting, with two fields - name and > > > value. The problem with this, however, is that if the project is reset > > > - as it often is at the moment as I am playing around with the models > > > a lot - all the rows in the settings table are lost, and therefore all > > > the values. > > > > Is there a commonly "accepted" way to achieve what I am doing here? > > > How does one store variables which don't really conform strictly to > > > the "model". I want these values to be changeable via views in the web > > > interface. > > > There's really only two places you can store this sort of thing - > > settings files, or a model. If you put it in a settings file, it won't > > get lost in a reset, but users won't be able to change them; if you > > put them in a model, users will change them, but they will be > > susceptible to loss. > > > If you need users to be able to change the values, then using the > > settings file obviously isn't an option. This just leaves using > > tables, and managing the reset process so you don't lose data. > > > Django doesn't have anything built-in to make sure data isn't lost > > during a reset - mostly because the point of a reset is to lose data > > :-) However, you can use the dumpdata and loaddata management commands > > to make it easier to save and restore specific table data; you can > > also use the initial_data fixture to ensure than an application always > > has appropriate initial values. > > > Also - I would be remiss if I didn't point you at a reusable app that > > was designed specifically for this problem: > > >http://code.google.com/p/django-values/ > > > I haven't used it myself, but Marty is a well respected member of the > > Django community, so I'm fairly confident his code will be fairly > > usable. > > > Yours, > > Russ Magee %-) > > I don't know how well Marty maintains it, but if it doesn't work out for you > the satchmo guys have a nice fork of it that's obviously actively worked on, > so you can always use it(with minimal other bits from stachmo) if it works > better for you. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
