I read a JSON file for configuration information that the Django app needs. Rather than read it every time, I'd like to keep it in memory somewhere. Only, I don't know how to do this in Django. What's the best way to keep simple configuration information in RAM, so that it's accessible anywhere in the app?
You can keep the variables that you want to access as Environment variables and access them in your code.
export AWS_ACCESS_KEY = "<your_key>" # set environment variable
os.getenv('AWS_ACCESS_KEY') # access environment variable in your code
I'd suggest you to version control what ever config it is and use it to run the system the reason being it will be extremely difficult to replicate or debug these kind of issues.
But if you feel your scenario is exceptional your best go will be global variables.
You can use a global variable in other functions by declaring it as global in each function that assigns to it
Related
I have defined a 'Global' variable for 'postman' to be used under the postman's documentation.
However after loading the documentation it looks like the variable is not coming through at all. I can see what its assigned to but not the actual expected value is there.
If I set this variable under a particular environment then it works fine.
Is there anything preventing global variables to work in documentation? has anyone else faced this same issue?
p.s I know variables in lower levels take precedence so I have removed them from all environments and only have them set in Global. Any help is appreciated
based on answer from #dannydainton above who works for Postman:
The functionality isn't there to be able to use global variables for
the documentation. Using the Environment or Collection level ones
would be the other options.
Can someone help me?
is it posible to store a variable on the local storage of my watch, so my app can read those settings as it starts?
Yes, it is possible and you have several options. The best choice mostly depends on what kind of information you want to store. If it's just a single variable, the easiest way is to store it in either the Info.plist file of your app or to store it in a file.
If you want to store more complex data, you can store it in a database.
I use the GDAL. CPLSetConfigOption("GDAL_DATA", "mygdaldir") works, but throws an exception when finishing the app. It is possible to set GDAL_DATA as "global" environment variable but I want to do it programmatically for the current process instead of configure it externally.
Any ways how to set an environment variable for the current process/app itself?
EDIT:
Found the problem: GDAL_DATA pointed to the wrong directory => GDAL fails to unload correctly. Anyway, #Greenflow gives us a fitting answer to my question and even if I don't need his solution I accepted his answer.
You might want to read the docs for qgetenv and qputenv.
I want to know what are the best ways/practices of handling user settings in a program. I'm writing a program and want to allow users to save settings which can be loaded automatically as soon as the program starts. I'm not just asking for codes, but the best practices of handling such as how to handle the settings at run time, should I need to create an object such as UserSettings (I'm using Java)? Which format is best for saving the settings (XML/JSON?)? Is it good to have the file format human readable? what are the things that I should take care of? I like to hear the thoughts/advices of some professional stackoverflow users out there.
Having a human-readable format is great; if for some reason a setting makes the program completely unusable it is then possible to go in and frob the setting to something sane.
If your users will roam from computer to computer then having user settings in a database or some centralised repository makes sense.
Otherwise, a locally-saved, human-readable .INI (with named sections) or a .XML file.
If using a .XML file, try to avoid making it too 'dense', and sprinkle with appropriate comments.
Say I have ini/json to store configuration setting of my desktop application,Will it be ok to have a static object with all property loaded at startup/when ever it is required or is there any other better alternative?
Since this is the very first time I am doing this ,so just wanted to know whether static object is fine or singleton pattern or something else would be better
I usually use Boost.Program_options, and I usually use a singleton.
Either way is fine.
If it was me, I would have it on construction of the config object.
cConfig Config("config.ini");
This Config class would load the settings found in the file. Any code can access the settings by doing
Config.Get("NumberOfFoobars")
For testability purposes, if there is no file in the construction, the class' settings is set to default or a log file is created with a line advising the user of the missing settings.
And then for functions that needs the config, I would pass the Config instance as part of the parameters:
DoStuff(Config, [...]);
and have DoStuff get the variables from the Config class.
This makes the class testable (you can mock Config class), readeable (at a glance, you can tell which function requires Configs) and you don't have to rely on static instances (singletons are dangerous if you don't know how to use them).
You might be interested to learn more about this
If the config settings is going to be modified by the user to determine the way the application is going to run, then it might be better to keep it in some ini file. Some users like to edit ini files directly rather than do it through the GUI. It is better to give both the options.
Also some user have multiple ini files and rotate among them for settings they need at that point of time.
Loading all your settings at startup (or the first time a setting is needed) will work most of the time, but the user will have to restart the application in order for any edits to the config file to take effect. For most users this will never be an issue, but for advanced users who like to edit config files directly this could be frustrating. On UNIX based OSs it is possible to handle the SIGHUP signal which has become a accepted trigger to re-read configuration files. There is no similar method that I know of for Windows. An alternative approach would be to keep track of the modification time of the config file to determine if the settings should be re-read.