openedx.core.djangoapps.util.management.commands package#
Submodules#
openedx.core.djangoapps.util.management.commands.dump_settings module#
Defines the dump_settings management command.
- class openedx.core.djangoapps.util.management.commands.dump_settings.Command(stdout=None, stderr=None, no_color=False, force_color=False)#
Bases:
BaseCommandDump current Django settings to JSON for debugging/diagnostics.
BEWARE: OUTPUT IS NOT SUITABLE FOR CONSUMPTION BY PRODUCTION SYSTEMS. The purpose of this output is to be helpful for a human operator to understand how their settings are being rendered and how they differ between different settings files. The serialization format is NOT perfect: there are certain situations where two different settings will output identical JSON. For example, this command does NOT:
disambiguate between lists and tuples: * (1, 2, 3) # <– this tuple will be printed out as [1, 2, 3] * [1, 2, 3]
disambiguate between sets and sorted lists: * {2, 1, 3} # <– this set will be printed out as [1, 2, 3] * [1, 2, 3]
disambiguate between internationalized and non-internationalized strings: * _(“hello”) # <– this will become just “hello” * “hello”
Furthermore, functions and classes are printed as JSON objects like: {
“module”: “path.to.module”, “qualname”: “MyClass.MyInnerClass.my_method”, // Or, “<lambda>” “source_hint”: “MY_SETTING = lambda: x + y”, // For <lambda>s only
}
And everything else will be stringified as its repr(…).
- handle(*args, **kwargs)#
Handle the command.
openedx.core.djangoapps.util.management.commands.print_setting module#
print_setting#
Django command to output a single Django setting. Originally used by “paver” scripts before we removed them. Still useful when a shell script needs such a value. Keep in mind that the LMS/CMS startup time is slow, so if you invoke this Django management multiple times in a command that gets run often, you are going to be sad.
This handles the one specific use case of the “print_settings” command from django-extensions that we were actually using.
- class openedx.core.djangoapps.util.management.commands.print_setting.Command(stdout=None, stderr=None, no_color=False, force_color=False)#
Bases:
BaseCommandprint_setting command
- add_arguments(parser)#
Entry point for subclassed commands to add custom arguments.
- handle(*args, **options)#
The actual logic of the command. Subclasses must implement this method.
- help = 'Print the value of a single Django setting.'#
openedx.core.djangoapps.util.management.commands.reset_db module#
reset_db#
Django command to drop and recreate a database. Useful when running tests against a database which may previously have had different migrations applied to it.
This handles the one specific use case of the “reset_db” command from django-extensions that we were actually using.
originally from http://www.djangosnippets.org/snippets/828/ by dnordberg
- class openedx.core.djangoapps.util.management.commands.reset_db.Command(stdout=None, stderr=None, no_color=False, force_color=False)#
Bases:
BaseCommand- add_arguments(parser)#
Entry point for subclassed commands to add custom arguments.
- handle(*args, **options)#
Resets the database for this project.
Note: Transaction wrappers are in reverse as a work around for autocommit, anybody know how to do this the right way?
- help = 'Resets the database for this project.'#
- openedx.core.djangoapps.util.management.commands.reset_db.parse_mysql_cnf(dbinfo)#
Attempt to parse mysql database config file for connection settings. Ideally we would hook into django’s code to do this, but read_default_file is handled by the mysql C libs so we have to emulate the behaviour
Settings that are missing will return ‘’ returns (user, password, database_name, database_host, database_port)