Este es el comando django-admin que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
django-admin: script de utilidad para el marco web de Django
administrador-django es la utilidad de línea de comandos de Django para tareas administrativas. Este documento
describe todo lo que puede hacer.
Antes de Django 1.7, administrador-django solo se instaló como django-admin.py.
Además, manage.py se crea automáticamente en cada proyecto de Django. manage.py es un
envoltura delgada alrededor administrador-django que se encarga de varias cosas por ti antes
delegando a administrador-django:
· Pone el paquete de tu proyecto en sys.ruta.
· Establece el DJANGO_SETTINGS_MODULE variable de entorno para que apunte a su
proyecto settings.py archivo.
· Se llama django.configuración() para inicializar varias partes internas de Django.
django.configuración() no existía en versiones anteriores de Django.
El administrador-django El script debe estar en la ruta de su sistema si instaló Django a través de su
configuración.py utilidad. Si no está en su camino, puede encontrarlo en sitio-paquetes/django/bin
dentro de su instalación de Python. Considere vincularlo desde algún lugar en su camino, como
as / usr / local / bin.
Para los usuarios de Windows, que no tienen la función de enlace simbólico disponible, puede copiar
django-admin.exe a una ubicación en su ruta existente o edite el TRAYECTORIA ajustes (bajo
Ajustes - Control Panel - System - Avanzado - Medio ambiente...) para apuntar a su instalado
ubicación.
Generalmente, cuando se trabaja en un solo proyecto de Django, es más fácil de usar manage.py que
administrador-django. Si necesita cambiar entre múltiples archivos de configuración de Django, use
administrador-django DJANGO_SETTINGS_MODULE o de - ajustes opción de línea de comando.
Los ejemplos de línea de comandos a lo largo de este documento usan administrador-django ser coherente, pero
cualquier ejemplo puede usar manage.py igual de bien.
USO
$ django-admin [opciones]
$ administrar.py [opciones]
comando debe ser uno de los comandos enumerados en este documento. opciones, cual es
opcional, debe ser cero o más de las opciones disponibles para el comando dado.
Encontrar tiempo de ejecución ayuda
administrador-django ayuda
Ejecutar administrador-django ayuda para mostrar información de uso y una lista de los comandos proporcionados por
cada aplicación.
Ejecutar administrador-django ayuda --comandos para mostrar una lista de todos los comandos disponibles.
Ejecutar administrador-django ayuda para mostrar una descripción del comando dado y una lista
de sus opciones disponibles.
Aplicación nombres
Muchos comandos toman una lista de "nombres de aplicaciones". Un "nombre de la aplicación" es el nombre base del paquete
que contiene sus modelos. Por ejemplo, si tu APLICACIONES_INSTALADAS contiene la cadena
'misitio.blog', el nombre de la aplicación es blog.
Determinando las versión
administrador-django versión
Ejecutar administrador-django versión para mostrar la versión actual de Django.
La salida sigue el esquema descrito en PEP 386:
1.4.dev17026
1.4a1
1.4
Viendo depurar salida
Uso --verbosidad para especificar la cantidad de notificación e información de depuración que
administrador-django debe imprimir en la consola. Para obtener más detalles, consulte la documentación de la
--verbosidad .
DISPONIBLE COMANDOS
comprobar <nombre de la aplicación nombre de la aplicación ...>
administrador-django comprobar
Utiliza el te comprobar marco para inspeccionar todo el proyecto Django en busca de problemas comunes.
El marco de verificación del sistema confirmará que no hay ningún problema con su
modelos o sus registros de administrador. También proporcionará advertencias de compatibilidad común.
problemas introducidos al actualizar Django a una nueva versión. Se pueden introducir cheques personalizados
por otras bibliotecas y aplicaciones.
De forma predeterminada, se comprobarán todas las aplicaciones. Puede comprobar un subconjunto de aplicaciones proporcionando una lista
de etiquetas de aplicaciones como argumentos:
python manage.py comprobar auth admin myapp
Si no especifica ninguna aplicación, se comprobarán todas las aplicaciones.
--etiqueta
El te comprobar marco realiza muchos tipos diferentes de controles. Estos tipos de cheques son
categorizados con etiquetas. Puede utilizar estas etiquetas para restringir las comprobaciones realizadas a solo
aquellos en una categoría particular. Por ejemplo, para realizar solo seguridad y compatibilidad
comprobaciones, ejecutarías:
Python manage.py check --tag security --tag compatibilidad
--list-etiquetas
Muestra todas las etiquetas disponibles.
--desplegar
El --desplegar La opción activa algunas comprobaciones adicionales que solo son relevantes en un
configuración de implementación.
Puede usar esta opción en su entorno de desarrollo local, pero dado que su
El módulo de configuración de desarrollo puede no tener muchas de sus configuraciones de producción,
probablemente quiera señalar el comprobar comando en un módulo de configuración diferente, ya sea configurando
las DJANGO_SETTINGS_MODULE variable de entorno, o pasando la - ajustes opción:
python manage.py check --deploy --settings=configuraciones_de_producción
O puede ejecutarlo directamente en una implementación de producción o ensayo para verificar que el
los ajustes correctos están en uso (omitiendo - ajustes). Incluso podrías convertirlo en parte de tu
conjunto de pruebas de integración.
compilar mensajes
administrador-django compilar mensajes
Compila archivos .po creados por hacer mensajes a archivos .mo para usar con el gettext incorporado
apoyo. Ver / temas / i18n / index.
Ingrese al --lugar opción (o su versión más corta -l) para especificar las configuraciones regionales a procesar.
Si no se proporciona, se procesan todas las configuraciones regionales.
Ingrese al --excluir opción (o su versión más corta -x) para especificar la(s) localidad(es) a excluir
del procesamiento. Si no se proporciona, no se excluye ninguna configuración regional.
Puedes pasar --uso-difuso opción (o -f) para incluir traducciones difusas en archivos compilados.
Adicional --excluir y --uso-difuso .
Ejemplo de uso:
mensajes de compilación Django-admin --locale=pt_BR
mensajes de compilación Django-admin --locale=pt_BR --locale=fr -f
django-admin compilar mensajes -l pt_BR
django-admin compilar mensajes -l pt_BR -l fr --use-fuzzy
mensajes de compilación Django-admin --exclude=pt_BR
django-admin compilemessages --exclude = pt_BR --exclude = fr
django-admin compilar mensajes -x pt_BR
django-admin compilar mensajes -x pt_BR -x fr
crearcachetable
administrador-django crearcachetable
Crea las tablas de caché para usar con el backend de caché de la base de datos. Ver /temas/caché para
más información.
El --base de datos La opción se puede utilizar para especificar la base de datos en la que la tabla de caché se
estar instalado.
Ya no es necesario proporcionar el nombre de la tabla de caché o el --base de datos opción. Django
toma esta información de su archivo de configuración. Si ha configurado varios cachés o
múltiples bases de datos, se crean todas las tablas de caché.
shell de base de datos
administrador-django shell de base de datos
Ejecuta el cliente de línea de comandos para el motor de base de datos especificado en su MOTOR ajuste,
con los parámetros de conexión especificados en su USUARIO, CONTRASEÑA, etc., ajustes.
· Para PostgreSQL, esto ejecuta el psql cliente de línea de comandos.
· Para MySQL, esto ejecuta el mysql cliente de línea de comandos.
· Para SQLite, esto ejecuta el sqlite3 cliente de línea de comandos.
Este comando asume que los programas están en su TRAYECTORIA para que una simple llamada al programa
nombre (psql, mysql, sqlite3) encontrará el programa en el lugar adecuado. no hay manera de
especificar la ubicación del programa manualmente.
El --base de datos La opción se puede utilizar para especificar la base de datos en la que abrir un shell.
ajustes
administrador-django ajustes
Muestra las diferencias entre el archivo de configuración actual y la configuración predeterminada de Django.
Los ajustes que no aparecen en los valores predeterminados van seguidos de "###". Por ejemplo, el valor predeterminado
la configuración no define ROOT_URLCONF, asi que ROOT_URLCONF es seguido por "###" en la salida de
ajustes.
El --todas Se puede proporcionar la opción para mostrar todas las configuraciones, incluso si tienen Django.
valor por defecto. Dichas configuraciones tienen el prefijo "###".
datos de volcado <etiqueta_aplicación etiqueta_aplicación etiqueta_aplicación.Modelo ...>
administrador-django datos de volcado
Envía a la salida estándar todos los datos en la base de datos asociados con el nombre
aplicación (es).
Si no se proporciona un nombre de aplicación, se descartarán todas las aplicaciones instaladas.
La salida de datos de volcado se puede utilizar como entrada para Cargar datos.
Tenga en cuenta que datos de volcado utiliza el administrador predeterminado en el modelo para seleccionar los registros a
vertedero. Si estás usando un personalizado gerente como administrador predeterminado y filtra algunos de los
registros disponibles, no todos los objetos serán volcados.
El --todas Se puede proporcionar una opción para especificar que datos de volcado debería usar la base de Django
administrador, volcando registros que de otro modo podrían ser filtrados o modificados por una costumbre
gerente.
--formato
De forma predeterminada, datos de volcado formateará su salida en JSON, pero puede usar el --formato opción
para especificar otro formato. Los formatos admitidos actualmente se enumeran en
serialización-formatos.
--sangrar
De forma predeterminada, datos de volcado generará todos los datos en una sola línea. Esto no es fácil para los humanos
leer, para que puedas usar el --sangrar opción para imprimir de forma bonita la salida con una serie de
espacios de sangría.
El --excluir Se puede proporcionar una opción para evitar aplicaciones o modelos específicos (especificados).
como en forma de etiqueta_aplicación.ModelName) de ser arrojado. Si especifica un nombre de modelo para
datos de volcado, la salida volcada se restringirá a ese modelo, en lugar de a todo el
solicitud. También puede mezclar nombres de aplicaciones y nombres de modelos.
El --base de datos La opción se puede utilizar para especificar la base de datos desde la que se descargarán los datos.
--natural-extranjero
Cuando se especifica esta opción, Django utilizará el natural_key () método de modelo para serializar
cualquier clave externa y relación de muchos a muchos con objetos del tipo que define el
método. Si estás tirando contribución.auth Permiso objetos o contribución.tipos de contenido
Tipo de contenido objetos, probablemente deberías estar usando esta bandera. Ver el natural claves
documentación para obtener más detalles sobre esta y la siguiente opción.
--primario-natural
Cuando se especifica esta opción, Django no proporcionará la clave principal en el serializado
datos de este objeto, ya que se puede calcular durante la deserialización.
--natural
En desuso desde la versión 1.7: Equivalente a la --natural-extranjero opción; usa eso
preferiblemente.
Uso natural claves para representar cualquier clave externa y una relación de muchos a muchos con un modelo
que proporciona una definición de clave natural.
--paquetes
De forma predeterminada, datos de volcado generará todos los registros del modelo, pero puede usar el --paquetes
opción para especificar una lista separada por comas de claves primarias sobre las que filtrar. Esto es sólo
disponible al volcar un modelo.
--producción
Por defecto datos de volcado enviará todos los datos serializados a la salida estándar. Estas opciones
permite especificar el archivo en el que se escribirán los datos.
enjuagar
administrador-django enjuagar
Elimina todos los datos de la base de datos, vuelve a ejecutar los controladores posteriores a la sincronización y
reinstala cualquier accesorio de datos inicial.
El --sin entrada se puede proporcionar la opción para suprimir todas las indicaciones del usuario.
El --base de datos La opción se puede utilizar para especificar la base de datos que se debe vaciar.
--sin-datos-iniciales
Uso --sin-datos-iniciales para evitar cargar el accesorio initial_data.
inspeccionardb
administrador-django inspeccionardb
Introspecciona las tablas de la base de datos y las vistas en la base de datos apuntada por el NOMBRE pólipo
y genera un módulo de modelo de Django (un modelos.py archivo) a la salida estándar.
Use esto si tiene una base de datos heredada con la que le gustaría usar Django. La secuencia de comandos
inspeccionará la base de datos y creará un modelo para cada tabla o vista dentro de ella.
Como era de esperar, los modelos creados tendrán un atributo para cada campo en el
tabla o vista. Tenga en cuenta que inspeccionardb tiene algunos casos especiales en su salida de nombre de campo:
· Si inspeccionardb no puede asignar el tipo de una columna a un tipo de campo modelo, usará Campo de texto y
insertará el comentario de Python 'Esta campo tipo is a adivinar.' junto al campo en el
modelo generado.
· Si el nombre de la columna de la base de datos es una palabra reservada de Python (como 'aprobar', 'clase' or
'por'), inspeccionardb agregará '_campo' al nombre del atributo. Por ejemplo, si una mesa
tiene una columna 'por', el modelo generado tendrá un campo 'for_field', Con el
columna_db atributo establecido en 'por'. inspeccionardb insertará el comentario de Python 'Campo
rebautizado porque it fue a Python reservados palabra.' junto al campo.
Esta característica está pensada como un atajo, no como una generación de modelo definitiva. Después de ejecutarlo,
deseará revisar los modelos generados usted mismo para realizar personalizaciones. En
particular, deberá reorganizar el orden de los modelos, de modo que los modelos que se refieren a otros
los modelos están ordenados correctamente.
Las claves primarias se introspeccionan automáticamente para PostgreSQL, MySQL y SQLite, en las que
caso Django pone en el clave_principal=Verdadero donde sea necesario.
inspeccionardb trabaja con PostgreSQL, MySQL y SQLite. La detección de clave externa solo funciona en
PostgreSQL y con ciertos tipos de tablas MySQL.
Django no crea valores predeterminados de base de datos cuando un tu préstamo estudiantil se especifica en un campo de modelo.
De manera similar, los valores predeterminados de la base de datos no se traducen a valores predeterminados de campo del modelo ni se detectan en ningún
moda por inspeccionardb.
De forma predeterminada, inspeccionardb crea modelos no administrados. Es decir, gestionado = Falso en el modelo
Meta class le dice a Django que no administre la creación, modificación y eliminación de cada tabla.
Si desea permitir que Django administre el ciclo de vida de la tabla, deberá cambiar el
gestionado opción de ¿Editas con tu equipo de forma remota? (o simplemente eliminarlo porque ¿Editas con tu equipo de forma remota? es su valor predeterminado).
El --base de datos La opción se puede utilizar para especificar la base de datos para la introspección.
Se agregó una función para inspeccionar las vistas de la base de datos. En versiones anteriores, solo las tablas (no
vistas) fueron inspeccionadas.
Cargar datos <accesorio accesorio ...>
administrador-django Cargar datos
Busca y carga el contenido del dispositivo nombrado en la base de datos.
El --base de datos La opción se puede utilizar para especificar la base de datos en la que se guardarán los datos.
cargado
--ignorenoexistente
El --ignorenoexistente La opción se puede usar para ignorar campos y modelos que pueden haber sido
eliminado ya que el accesorio se generó originalmente.
--aplicación
El --aplicación La opción se puede usar para especificar una sola aplicación para buscar accesorios en lugar de
mirando todas las aplicaciones.
--aplicación fue añadido.
--ignorenoexistente también ignora modelos inexistentes.
Qué está haciendo a accesorio ?
A accesorio es una colección de archivos que contienen el contenido serializado de la base de datos.
Cada aparato tiene un nombre único y los archivos que componen el aparato se pueden distribuir
en múltiples directorios, en múltiples aplicaciones.
Django buscará accesorios en tres ubicaciones:
1. En el accesorios directorio de cada aplicación instalada
2. En cualquier directorio nombrado en el FIXTURE_DIRS pólipo
3. En la ruta literal nombrada por el dispositivo
Django cargará todas y cada una de las luminarias que encuentre en estas ubicaciones que coincidan con las proporcionadas
nombres de accesorios.
Si el aparato nombrado tiene una extensión de archivo, solo se cargarán aparatos de ese tipo. Para
ejemplo:
django-admin cargar datos mydata.json
solo cargaría accesorios JSON llamados mis datos. La extensión de la luminaria debe corresponder a la
nombre registrado de un serializador (p.ej, json or xml).
Si omite las extensiones, Django buscará todos los tipos de aparatos disponibles para encontrar una coincidencia.
accesorio. Por ejemplo:
django-admin cargar datos mis datos
buscaría cualquier dispositivo de cualquier tipo de dispositivo llamado mis datos. Si un directorio de accesorios
contenida misdatos.json, ese dispositivo se cargaría como un dispositivo JSON.
Los aparatos que se nombran pueden incluir componentes de directorio. Estos directorios serán
incluido en la ruta de búsqueda. Por ejemplo:
django-admin loaddata foo / bar / mydata.json
buscaría /accesorios/foo/bar/mydata.json para cada aplicación instalada,
/foo/bar/misdatos.json para cada directorio en FIXTURE_DIRS, y la ruta literal
foo / bar / mydata.json.
Cuando se procesan los archivos de accesorios, los datos se guardan en la base de datos tal cual. Modelo definido
ahorrar() los métodos no son llamados, y cualquier pre_guardar or publicar_guardar las señales serán llamadas con
raw = Verdadero ya que la instancia solo contiene atributos que son locales para el modelo. Puedes,
por ejemplo, desea deshabilitar los controladores que acceden a campos relacionados que no están presentes
durante la carga del dispositivo y, de lo contrario, generaría una excepción:
desde django.db.models.signals importar post_save
desde .models importar MyModel
def my_handler (** kwargs):
# deshabilitar el controlador durante la carga del dispositivo
si kwargs['en bruto']:
volvemos
...
post_save.connect (my_handler, sender = MyModel)
También podría escribir un decorador simple para encapsular esta lógica:
desde functools importar envolturas
def disable_for_loaddata (manejador_de_señal):
""
Decorador que desactiva los controladores de señal al cargar datos de dispositivos.
""
@wraps(controlador_señal)
envoltorio def(*args, **kwargs):
si kwargs['en bruto']:
volvemos
controlador_señal(*argumentos, **kwargs)
envoltorio de devolución
@disable_for_loaddata
def my_handler (** kwargs):
...
Solo tenga en cuenta que esta lógica deshabilitará las señales cada vez que se deserialicen los dispositivos,
no solo durante Cargar datos.
Tenga en cuenta que el orden en que se procesan los archivos de dispositivos no está definido. Sin embargo, todos
Los datos del dispositivo se instalan como una sola transacción, por lo que los datos en un dispositivo pueden hacer referencia
datos en otro dispositivo. Si el backend de la base de datos admite restricciones a nivel de fila, estas
Las restricciones se verificarán al final de la transacción.
El datos de volcado El comando se puede utilizar para generar entradas para Cargar datos.
Comprimido accesorios
Los accesorios se pueden comprimir en Código Postal, gzo bz2 formato. Por ejemplo:
django-admin cargar datos mydata.json
buscaría cualquiera de misdatos.json, misdatos.json.zip, misdatos.json.gzo misdatos.json.bz2.
Se utiliza el primer archivo contenido en un archivo comprimido zip.
Tenga en cuenta que si se descubren dos aparatos con el mismo nombre pero diferente tipo de aparato
(por ejemplo, si misdatos.json y misdatos.xml.gz se encontraron en el mismo directorio de dispositivos),
la instalación del accesorio será abortada, y cualquier dato instalado en la llamada a Cargar datos seguirá
ser eliminado de la base de datos.
MySQL con MyISAM y accesorios
El motor de almacenamiento MyISAM de MySQL no admite transacciones ni restricciones,
por lo tanto, si usa MyISAM, no obtendrá la validación de los datos del dispositivo ni una reversión si
se encuentran varios archivos de transacciones.
Específico de la base de datos accesorios
Si está en una configuración de múltiples bases de datos, es posible que tenga datos de dispositivos que desee cargar
en una base de datos, pero no en otra. En esta situación, puede agregar una base de datos
identificador en los nombres de sus aparatos.
Por ejemplo, si tu BASES DE DATOS la configuración tiene una base de datos 'maestra' definida, asigne un nombre al dispositivo
misdatos.master.json or mydata.master.json.gz y el dispositivo solo se cargará cuando
especificar que desea cargar datos en el dominar base de datos.
hacer mensajes
administrador-django hacer mensajes
Recorre todo el árbol de fuentes del directorio actual y extrae todas las cadenas marcadas
para traducir. Crea (o actualiza) un archivo de mensajes en conf/locale (en Django
tree) o locale (para proyecto y aplicación) directorio. Después de hacer cambios en el
archivos de mensajes con los que necesita compilarlos compilar mensajes para usar con el incorporado
obtener soporte de texto. Ver el i18n documentación para obtener más detalles.
--todas
Ingrese al --todas or -a opción para actualizar los archivos de mensajes para todos los idiomas disponibles.
Ejemplo de uso:
django-admin makemessages --todos
--extensión
Ingrese al --extensión or -e opción para especificar una lista de extensiones de archivo para examinar (predeterminado:
".html", ".txt").
Ejemplo de uso:
django-admin makemessages --locale = de --extension xhtml
Separe varias extensiones con comas o use -e o --extension varias veces:
django-admin makemessages --locale = de --extension = html, txt --extension xml
Ingrese al --lugar opción (o su versión más corta -l) para especificar las configuraciones regionales a procesar.
Ingrese al --excluir opción (o su versión más corta -x) para especificar la(s) localidad(es) a excluir
del procesamiento. Si no se proporciona, no se excluye ninguna configuración regional.
Ejemplo de uso:
django-admin crear mensajes --locale=pt_BR
django-admin crear mensajes --locale=pt_BR --locale=fr
django-admin crear mensajes -l pt_BR
django-admin crear mensajes -l pt_BR -l fr
django-admin crear mensajes --exclude=pt_BR
django-admin makemessages --exclude = pt_BR --exclude = fr
Django-admin makemessages -x pt_BR
django-admin hacer mensajes -x pt_BR -x fr
Agregó el --anterior opción a la fusionar mensaje comando cuando se fusiona con archivos po existentes.
--dominio
Ingrese al --dominio or -d opción para cambiar el dominio de los archivos de mensajes. Actualmente
apoyado:
· django para todos * .py, * .html y * .txt archivos (predeterminado)
· djangojs para * .js archivos
--enlaces simbólicos
Ingrese al --enlaces simbólicos or -s opción para seguir enlaces simbólicos a directorios al buscar nuevos
cadenas de traducción.
Ejemplo de uso:
django-admin makemessages --locale=de --enlaces simbólicos
--ignorar
Ingrese al --ignorar or -i opción para ignorar archivos o directorios que coincidan con el dado glob-Estilo
patrón. Use varias veces para ignorar más.
Estos patrones se utilizan por defecto: 'CVS', '. *', '*~', '*.pyc'
Ejemplo de uso:
django-admin makemessages --locale = en_US --ignore = apps / * --ignore = secret / *. html
--no-predeterminado-ignorar
Ingrese al --no-predeterminado-ignorar opción para deshabilitar los valores predeterminados de --ignorar.
--no envolver
Ingrese al --no envolver opción para deshabilitar dividir líneas largas de mensajes en varias líneas en
archivos de lenguaje.
--no-ubicación
Ingrese al --no-ubicación opción de no escribir '#: nombre de archivo: línea'líneas de comentarios en el idioma
archivos. Tenga en cuenta que el uso de esta opción hace que sea más difícil para los traductores técnicamente capacitados
comprender el contexto de cada mensaje.
--mantenimiento
Ingrese al --mantenimiento opción para evitar que Django elimine los errores de depuración temporales
lo que puede impedir que se creen los archivos de idioma finales.
VEA ADEMÁS:
See personalizar-hacer-mensajes para obtener instrucciones sobre cómo personalizar las palabras clave que
hacer mensajes pasa a xgettexto.
hacer migraciones [ ]
administrador-django hacer migraciones
Crea nuevas migraciones en función de los cambios detectados en sus modelos. Migraciones, sus
la relación con las aplicaciones y más se tratan en profundidad en las migraciones documentación.
Proporcionar uno o más nombres de aplicaciones como argumentos limitará las migraciones creadas al
aplicaciones especificadas y las dependencias necesarias (la tabla en el otro extremo de una Clave externa,
por ejemplo).
--vacío
El --vacío la opción causará hacer migraciones para generar una migración vacía para el
aplicaciones especificadas, para la edición manual. Esta opción es solo para usuarios avanzados y no debe
utilizarse a menos que esté familiarizado con el formato de migración, las operaciones de migración y la
dependencias entre sus migraciones.
- corrida en seco
El - corrida en seco La opción muestra qué migraciones se realizarían sin escribir ninguna
migraciones de archivos a disco. Usando esta opción junto con --verbosidad 3 también mostrará el
completar los archivos de migraciones que se escribirían.
--unir
El --unir La opción permite solucionar los conflictos migratorios. El --sin entrada la opción puede ser
proporcionado para suprimir las indicaciones del usuario durante una fusión.
--nombre, -n
El --nombre La opción le permite dar a la(s) migración(es) un nombre personalizado en lugar de un nombre generado.
uno.
--Salida, -e
El --Salida la opción causará hacer migraciones para salir con el código de error 1 cuando no hay migración
son creados (o habrían sido creados, si se combinaran con - corrida en seco).
migrado [ [ ]]
administrador-django migrado
Sincroniza el estado de la base de datos con el conjunto actual de modelos y migraciones.
Las migraciones, su relación con las aplicaciones y más se tratan en profundidad en las migraciones
documentación.
El comportamiento de este comando cambia según los argumentos proporcionados:
· Sin argumentos: todas las aplicaciones migradas tienen todas sus migraciones ejecutadas y todas las no migradas
las aplicaciones se sincronizan con la base de datos,
· : La aplicación especificada tiene sus migraciones ejecutadas, hasta la migración más reciente.
Esto puede implicar también ejecutar migraciones de otras aplicaciones, debido a dependencias.
· : lleva el esquema de la base de datos a un estado en el que el nombre
se aplica la migración, pero no se aplican migraciones posteriores en la misma aplicación. Esto puede
implican no aplicar migraciones si ha migrado previamente más allá de la migración nombrada.
Usa el nombre cero para cancelar todas las migraciones de una aplicación.
Diferente a la sincronizar, este comando no le solicita que cree un superusuario si no existe uno
(asumiendo que estás usando django.contrib.auth). Usar crea superusuario para hacer eso si lo deseas.
El --base de datos La opción se puede utilizar para especificar la base de datos a migrar.
--falso
El --falso opción le dice a Django que marque las migraciones como aplicadas o no aplicadas,
pero sin ejecutar el SQL para cambiar el esquema de su base de datos.
Esto está destinado a usuarios avanzados para manipular el estado de migración actual directamente si
están aplicando cambios manualmente; ten en cuenta que el uso de --falso corre el riesgo de poner
la tabla de estado de migración a un estado en el que se necesitará una recuperación manual para realizar
las migraciones se ejecutan correctamente.
--falso-inicial
El --falso-inicial La opción se puede usar para permitir que Django omita la migración inicial de una aplicación.
si todas las tablas de la base de datos con los nombres de todos los modelos creados por todos CreateModel operaciones
en esa migración ya existen. Esta opción está diseñada para usarse cuando se ejecuta por primera vez
migraciones contra una base de datos que preexistía al uso de migraciones. Esta opción no,
sin embargo, compruebe el esquema de la base de datos coincidente más allá de los nombres de las tablas coincidentes, por lo que solo
seguro de usar si está seguro de que su esquema existente coincide con lo que está registrado en
su migración inicial.
En desuso desde la versión 1.8: El --lista La opción se ha movido a la espectáculomigraciones
mando.
runfcgi [opciones]
administrador-django runfcgi
En desuso desde la versión 1.7: la compatibilidad con FastCGI está en desuso y se eliminará en Django
1.9.
Inicia un conjunto de procesos FastCGI adecuados para su uso con cualquier servidor web que admita
Protocolo FastCGI. Ver el FastCGI despliegue documentación para detalles. Requiere el
Módulo Python FastCGI de flipar.
Internamente, esto envuelve el objeto de la aplicación WSGI especificado por el WSGI_APLICACIÓN
ajuste.
Las opciones aceptadas por este comando se pasan a la biblioteca FastCGI y no usan el
'-' prefijo como es habitual para otros comandos de administración de Django.
protocolo
protocolo=PROTOCOLO
Protocolo a utilizar. PROTOCOLO puede ser fcgi, scgi, ajp, etc. (el valor predeterminado es fcgi)
fortaleza
host = HOSTNAME
Nombre de host para escuchar.
Puerto
puerto=PORTNUM
Puerto para escuchar.
enchufe
socket=ARCHIVO
Toma UNIX para escuchar.
Método
método=IMPL
Valores posibles: prefork or roscado (defecto prefork)
solicitudes máximas
maxrequests=NÚMERO
Número de solicitudes que maneja un niño antes de que se elimine y se bifurque un nuevo niño (0 significa
sin límite).
repuesto máximo
maxspare=NÚMERO
Número máximo de procesos / subprocesos de repuesto.
minutospare
minspare=NÚMERO
Número mínimo de procesos/subprocesos de repuesto.
maxniños
maxchildren=NÚMERO
Número de límite estricto de procesos / subprocesos.
demonizar
demonizar=BOOL
Ya sea para separarse de la terminal.
archivo pid
pidfile=ARCHIVO
Escriba el ID de proceso generado en el archivo ARCHIVO.
trabajodir
workdir=DIRECTORIO
Cambiar a directorio De miembros al demonizar.
depurar
depuración=BOOL
Establézcalo en verdadero para habilitar los rastreos flup.
fuera de línea
salida=ARCHIVO
Escriba stdout en el ARCHIVO archivo.
registro de errores
errlog = ARCHIVO
Escriba stderr en el ARCHIVO archivo.
umask
umask=UMASK
Umask para usar al demonizar. El valor se interpreta como un número octal (valor predeterminado
is 0o22).
Ejemplo de uso:
django-admin runfcgi socket=/tmp/fcgi.sock método=prefork daemonize=true \
pidfile=/var/ejecutar/django-fcgi.pid
Ejecute un servidor FastCGI como un demonio y escriba el PID generado en un archivo.
runserver [Puerto or dirección: puerto]
administrador-django runserver
Inicia un servidor web de desarrollo ligero en la máquina local. Por defecto, el servidor
se ejecuta en el puerto 8000 en la dirección IP 127.0.0.1. Puede pasar una dirección IP y un puerto
número de forma explícita.
Si ejecuta este script como un usuario con privilegios normales (recomendado), es posible que no tenga
acceso para iniciar un puerto en un número de puerto bajo. Los números de puerto bajos están reservados para
superusuario (raíz).
Este servidor utiliza el objeto de aplicación WSGI especificado por el WSGI_APLICACIÓN ajuste.
NO USE ESTE SERVIDOR EN UN ENTORNO DE PRODUCCIÓN. No ha pasado por auditorías de seguridad o
pruebas de rendimiento. (Y así es como se mantendrá. Estamos en el negocio de hacer Web
frameworks, no servidores web, por lo que mejorar este servidor para poder manejar una producción
El entorno está fuera del alcance de Django).
El servidor de desarrollo recarga automáticamente el código Python para cada solicitud, según sea necesario. Ustedes
no es necesario reiniciar el servidor para que los cambios en el código surtan efecto. Sin embargo, algunas acciones
como agregar archivos no desencadenan un reinicio, por lo que deberá reiniciar el servidor en estos
casos.
La compilación de archivos de traducción ahora también reinicia el servidor de desarrollo.
Si está utilizando Linux e instala pyinotificar, las señales del núcleo se utilizarán para recargar automáticamente
el servidor (en lugar de sondear las marcas de tiempo de modificación del archivo cada segundo). Esto ofrece
mejor escalado a grandes proyectos, reducción en el tiempo de respuesta a la modificación del código, más
detección robusta de cambios y reducción del uso de la batería.
pyinotificar Se agregó soporte.
Cuando inicia el servidor, y cada vez que cambia el código de Python mientras el servidor está
en ejecución, el servidor comprobará todo el proyecto de Django en busca de errores (consulte la comprobar
mando). Si se encuentran errores, se imprimirán en la salida estándar, pero no
detener el servidor.
Puede ejecutar tantos servidores como desee, siempre que estén en puertos separados. Sólo
ejecutar administrador-django runserver mas de una vez.
Tenga en cuenta que la dirección IP predeterminada, 127.0.0.1, no es accesible desde otras máquinas en su
red. Para hacer que su servidor de desarrollo sea visible para otras máquinas en la red, use
su propia dirección IP (p. ej. 192.168.2.1) o 0.0.0.0 or :: (con IPv6 habilitado).
Puede proporcionar una dirección IPv6 entre corchetes (p. ej. [200a :: 1]: 8000). Esta voluntad
activa automáticamente la compatibilidad con IPv6.
También se puede utilizar un nombre de host que contenga caracteres únicamente ASCII.
Si archivos estáticos la aplicación contrib está habilitada (predeterminado en nuevos proyectos) el runserver comando
será anulado con su propio runserver mando.
If migrado no se ejecutó previamente, la tabla que almacena el historial de migraciones es
creado en la primera ejecución de runserver.
--no recarga
Ingrese al --no recarga opción para deshabilitar el uso del cargador automático. Esto significa cualquier Python
los cambios de código que realice mientras el servidor se está ejecutando no surtirá efecto si el particular
Los módulos de Python ya se han cargado en la memoria.
Ejemplo de uso:
servidor de ejecución Django-admin --noreload
--sin enhebrar
El servidor de desarrollo es multiproceso de forma predeterminada. Utilizar el --sin enhebrar opción de
deshabilite el uso de subprocesos en el servidor de desarrollo.
--ipv6, -6
Ingrese al --ipv6 (o más corto -6) opción para decirle a Django que use IPv6 para el desarrollo
servidor. Esto cambia la dirección IP predeterminada de 127.0.0.1 a :: 1.
Ejemplo de uso:
servidor de ejecución de django-admin --ipv6
Ejemplos of usando una experiencia diferente puertos y direcciones
Puerto 8000 en la dirección IP 127.0.0.1:
servidor de ejecución Django-admin
Puerto 8000 en la dirección IP 1.2.3.4:
servidor de ejecución django-admin 1.2.3.4:8000
Puerto 7000 en la dirección IP 127.0.0.1:
servidor de ejecución django-admin 7000
Puerto 7000 en la dirección IP 1.2.3.4:
servidor de ejecución django-admin 1.2.3.4:7000
Puerto 8000 en dirección IPv6 :: 1:
servidor de ejecución Django-admin -6
Puerto 7000 en dirección IPv6 :: 1:
servidor de ejecución django-admin -6 7000
Puerto 7000 en dirección IPv6 2001:0db8:1234:5678::9:
django-admin runserver [2001:0db8:1234:5678::9]:7000
Puerto 8000 en la dirección IPv4 del host localhost:
django-admin servidor de ejecución localhost:8000
Puerto 8000 en la dirección IPv6 del host localhost:
servidor de ejecución django-admin -6 localhost: 8000
Entregando a estático archivos las Desarrollo servidor
De forma predeterminada, el servidor de desarrollo no sirve ningún archivo estático para su sitio (como
Archivos CSS, imágenes, cosas debajo MEDIO_URL Etcétera). Si quieres configurar Django
para servir medios estáticos, lea /howto/archivos-estáticos/index.
shell
administrador-django shell
Inicia el intérprete interactivo de Python.
Django usará IPython or bpython si alguno está instalado. Si tienes una concha rica
instalado pero quiere forzar el uso del intérprete de Python "simple", use el --sencillo opción,
al igual que:
django-admin shell --simple
Si desea especificar IPython o bpython como su intérprete si tiene
ambos instalados puede especificar una interfaz de intérprete alternativa con el -i or
--interfaz opciones como esta:
IPython:
django-admin shell -i ipython
django-admin shell --interfaz ipython
bpython:
django-admin shell -i bpython
shell django-admin - interfaz bpython
Cuando se inicia el intérprete interactivo de Python "simple" (ya sea porque --sencillo fue
especificado o porque no hay otra interfaz interactiva disponible) lee el script
señalado por el INICIO DE PYTHON variable de entorno y la ~ / .pythonrc.py texto. Si tu
no desea este comportamiento, puede usar el --sin inicio opción. p.ej:
django-admin shell --simple --no-startup
espectáculomigraciones [ [ ]]
administrador-django espectáculomigraciones
Muestra todas las migraciones en un proyecto.
--lista, -l
El --lista lista todas las aplicaciones que conoce Django, las migraciones disponibles para
cada aplicación, y si cada migración se aplica o no (marcado por un [X] al lado de
nombre de la migración).
Las aplicaciones sin migraciones también se enumeran, pero tienen (no migraciones) impreso debajo de ellos.
--plan, -p
El --plan La opción muestra el plan de migración que seguirá Django para aplicar las migraciones. Ningún
las etiquetas de las aplicaciones proporcionadas se ignoran porque el plan podría ir más allá de esas aplicaciones. Igual que
--lista, las migraciones aplicadas están marcadas por un [X]. Para una verbosidad de 2 y superior, todos
También se mostrarán las dependencias de una migración.
sql <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django sql
Imprime las sentencias CREATE TABLE SQL para los nombres de aplicaciones dados.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
sqlall <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django sqlall
Imprime las sentencias SQL CREATE TABLE y de datos iniciales para los nombres de aplicaciones dados.
Consulte la descripción de sqlpersonalizado para obtener una explicación de cómo especificar los datos iniciales.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
El sql* los comandos de gestión ahora respetan el permitir_migrar() método de ENRUTADORES_BASE DE DATOS.
Si tiene modelos sincronizados con bases de datos no predeterminadas, use el --base de datos bandera para obtener SQL para
esos modelos (anteriormente siempre estarían incluidos en la salida).
sqlclear <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django sqlclear
Imprime las instrucciones SQL DROP TABLE para los nombres de aplicaciones dados.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
sqlpersonalizado <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django sqlpersonalizado
Imprime las declaraciones SQL personalizadas para los nombres de aplicaciones dados.
Para cada modelo en cada aplicación especificada, este comando busca el archivo
/sql/ .sql, Donde es el nombre de la aplicación y
es el nombre del modelo en minúsculas. Por ejemplo, si tiene una aplicación noticias que incluye un
Historia modelo, sqlpersonalizado intentará leer un archivo noticias / sql / story.sql y agregarlo al
salida de este comando.
Se espera que cada uno de los archivos SQL, si se proporciona, contenga SQL válido. Los archivos SQL se canalizan
directamente en la base de datos después de que todas las declaraciones de creación de tablas de los modelos hayan sido
ejecutado. Utilice este enlace SQL para realizar modificaciones en la tabla o insertar funciones SQL
en la base de datos.
Tenga en cuenta que el orden en que se procesan los archivos SQL no está definido.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
sqldropindexes <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django sqldropindexes
Imprime las sentencias DROP INDEX SQL para los nombres de aplicaciones dados.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
sqlflush
administrador-django sqlflush
Imprime las sentencias SQL que se ejecutarían para el enjuagar mando.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
índices sqlin <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django índices sqlin
Imprime las sentencias SQL CREATE INDEX para los nombres de aplicaciones dados.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
migrar sql
administrador-django migrar sql
Imprime el SQL para la migración nombrada. Esto requiere una conexión de base de datos activa, que
se usará para resolver nombres de restricciones; esto significa que debe generar el SQL contra un
copia de la base de datos en la que desea aplicarla posteriormente.
Tenga en cuenta que migrar sql no colorea su salida.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que generar el SQL.
--hacia atrás
De forma predeterminada, el SQL creado es para ejecutar la migración en la dirección de avance. Aprobar
--hacia atrás para generar el SQL para anular la aplicación de la migración en su lugar.
sqlsecuenciaset <etiqueta_aplicación etiqueta_aplicación ...>
administrador-django sqlsecuenciaset
Imprime las instrucciones SQL para restablecer las secuencias de los nombres de las aplicaciones dadas.
Las secuencias son índices utilizados por algunos motores de bases de datos para rastrear el siguiente número disponible para
campos incrementados automáticamente.
Utilice este comando para generar SQL que solucionará los casos en los que una secuencia no esté sincronizada con
sus datos de campo incrementados automáticamente.
El --base de datos La opción se puede utilizar para especificar la base de datos para la que imprimir el SQL.
migraciones de calabaza
administrador-django migraciones de calabaza
Aplasta las migraciones para etiqueta_aplicación hasta e incluyendo nombre_migración abajo en menos
migraciones, si es posible. Las migraciones aplastadas resultantes pueden convivir con las
los no aplastados de forma segura. Para obtener más información, lea aplastamiento de la migración.
--no-optimizar
De forma predeterminada, Django intentará optimizar las operaciones en sus migraciones para reducir la
tamaño del archivo resultante. Aprobar --no-optimizar si este proceso está fallando para usted o
creando migraciones incorrectas, aunque también presente un informe de error de Django sobre el
comportamiento, ya que la optimización está destinada a ser segura.
inicio de la aplicación [destino]
administrador-django inicio de la aplicación
Crea una estructura de directorio de la aplicación Django para el nombre de la aplicación en el directorio actual
o el destino dado.
Por defecto, el directorio creado contiene un modelos.py archivo y otros archivos de plantilla de la aplicación.
(Vea el fuente para obtener más detalles). Si solo se proporciona el nombre de la aplicación, el directorio de la aplicación
crearse en el directorio de trabajo actual.
Si se proporciona el destino opcional, Django usará ese directorio existente en lugar de
que crear uno nuevo. Puedes usar '.' para indicar el directorio de trabajo actual.
Por ejemplo:
django-admin startapp miaplicación /Users/jezdez/Code/miaplicación
--plantilla
Con la --plantilla opción, puede usar una plantilla de aplicación personalizada proporcionando la ruta
a un directorio con el archivo de plantilla de la aplicación o una ruta a un archivo comprimido (.tar.gz,
.tar.bz2, . Tgz, .tbz, .zip) que contiene los archivos de plantilla de la aplicación.
Por ejemplo, esto buscaría una plantilla de aplicación en el directorio dado al crear el
miaplicacion aplicación:
django-admin startapp --template = / Users / jezdez / Code / my_app_template myapp
Django también aceptará URL (http, https, ftp) a archivos comprimidos con la aplicación
archivos de plantilla, descargándolos y extrayéndolos sobre la marcha.
Por ejemplo, aprovechando la función de Github para exponer repositorios como archivos zip, puede
puede usar una URL como:
django-admin startapp --template = https: //github.com/githubuser/django-app-template/archive/master.zip myapp
Cuando Django copia los archivos de plantilla de la aplicación, también procesa ciertos archivos a través del
motor de plantillas: los archivos cuyas extensiones coinciden con las --extensión opción (py por defecto)
y los archivos cuyos nombres se pasan con el --nombre opción. La plantilla contexto usado es:
· Cualquier opción pasada al inicio de la aplicación comando (entre las opciones compatibles con el comando)
· nombre de la aplicación -- el nombre de la aplicación como se pasó al comando
· directorio_aplicaciones -- la ruta completa de la aplicación recién creada
· versión_docs -- la versión de la documentación: 'dev' or '1.x'
ADVERTENCIA:
Cuando los archivos de plantilla de la aplicación se procesan con el motor de plantillas de Django (por defecto
todos * .py files), Django también reemplazará todas las variables de plantilla extraviadas contenidas. Para
ejemplo, si uno de los archivos de Python contiene una cadena de documentación que explica un
función relacionada con la representación de plantillas, podría resultar en un ejemplo incorrecto.
Para solucionar este problema, puede utilizar el plantilla de etiqueta templatetag para "escapar" del
varias partes de la sintaxis de la plantilla.
inicioproyecto [destino]
administrador-django inicioproyecto
Crea una estructura de directorio de proyecto Django para el nombre de proyecto dado en el actual
directorio o el destino dado.
Por defecto, el nuevo directorio contiene manage.py y un paquete de proyecto (que contiene un
settings.py y otros archivos). Ver el plantilla fuente para obtener más detalles.
Si solo se da el nombre del proyecto, tanto el directorio del proyecto como el paquete del proyecto serán
llamado y el directorio del proyecto se creará en el trabajo actual
directorio.
Si se proporciona el destino opcional, Django usará ese directorio existente como el
directorio del proyecto y crear manage.py y el paquete del proyecto dentro de él. Usar '.' a
denotar el directorio de trabajo actual.
Por ejemplo:
django-admin startproject myproject / Users / jezdez / Code / myproject_repo
Al igual que con la inicio de la aplicación comando, el --plantilla opción le permite especificar un directorio, archivo
ruta o URL de una plantilla de proyecto personalizada. Ver el inicio de la aplicación documentación para detalles de
formatos de plantilla de proyecto admitidos.
Por ejemplo, esto buscaría una plantilla de proyecto en el directorio dado al crear
las mi proyecto proyecto:
django-admin startproject --template=/Users/jezdez/Code/my_project_template miproyecto
Django también aceptará URL (http, https, ftp) a archivos comprimidos con el proyecto
archivos de plantilla, descargándolos y extrayéndolos sobre la marcha.
Por ejemplo, aprovechando la función de Github para exponer repositorios como archivos zip, puede
puede usar una URL como:
django-admin startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip miproyecto
Cuando Django copia los archivos de plantilla del proyecto, también procesa ciertos archivos a través del
motor de plantillas: los archivos cuyas extensiones coinciden con las --extensión opción (py por defecto)
y los archivos cuyos nombres se pasan con el --nombre opción. La plantilla contexto usado es:
· Cualquier opción pasada al inicioproyecto comando (entre las opciones compatibles con el comando)
· nombre del proyecto -- el nombre del proyecto como se pasa al comando
· proyecto_directorio -- la ruta completa del proyecto recién creado
· llave secreta - una clave aleatoria para el LLAVE SECRETA pólipo
· versión_docs -- la versión de la documentación: 'dev' or '1.x'
Por favor también vea el representación advertencia como se mencionó para inicio de la aplicación.
sincronizar
administrador-django sincronizar
En desuso desde la versión 1.7: este comando ha quedado en desuso en favor del migrado
comando, que realiza tanto el comportamiento anterior como la ejecución de migraciones. Esto es ahora
solo un alias para ese comando.
Alias para migrado.
test <aplicación or test identificador>
administrador-django test
Ejecuta pruebas para todos los modelos instalados. Ver / temas / testing / index para obtener más información.
--Fallar rapido
El --Fallar rapido La opción se puede usar para detener la ejecución de pruebas e informar la falla inmediatamente.
después de que falla una prueba.
--corredor de pruebas
El --corredor de pruebas La opción se puede usar para controlar la clase de corredor de prueba que se usa para
ejecutar pruebas. Si se proporciona este valor, anula el valor proporcionado por el
PRUEBA_RUNNER ajuste.
--servidor en vivo
El --servidor en vivo La opción se puede usar para anular la dirección predeterminada donde el servidor en vivo
(usado con Caso de prueba de LiveServer) se espera que se ejecute. El valor predeterminado es
localhost: 8081.
--mantener db
El --mantener db La opción se puede utilizar para conservar la base de datos de prueba entre ejecuciones de prueba. Esto tiene
la ventaja de omitir las acciones de crear y destruir, lo que disminuye en gran medida la
tiempo para ejecutar pruebas, especialmente aquellas en un conjunto de pruebas grande. Si la base de datos de prueba no
existe, se creará en la primera ejecución y luego se conservará para cada ejecución posterior. Ningún
las migraciones no aplicadas también se aplicarán a la base de datos de prueba antes de ejecutar la prueba
sucesivamente.
--contrarrestar
El --contrarrestar La opción se puede utilizar para ordenar los casos de prueba en el orden opuesto. Esto puede ayudar
en pruebas de depuración que no están debidamente aisladas y tienen efectos secundarios. Agrupamiento by test
clase se conserva cuando se utiliza esta opción.
--depuración-sql
El --depuración-sql La opción se puede utilizar para habilitar SQL registro por fallar en las pruebas. Si --verbosidad
is 2, luego también se emiten las consultas en las pruebas aprobadas.
servidor de pruebas <accesorio accesorio ...>
administrador-django servidor de pruebas
Ejecuta un servidor de desarrollo Django (como en runserver) utilizando datos de los accesorios dados.
Por ejemplo, este comando:
django-admin servidor de pruebas mydata.json
... realizaría los siguientes pasos:
1. Cree una base de datos de prueba, como se describe en la base de datos de prueba.
2. Rellene la base de datos de prueba con datos de accesorios de los accesorios dados. (Para más información
accesorios, vea la documentación para Cargar datos encima.)
3. Ejecuta el servidor de desarrollo Django (como en runserver), señaló a este recién creado
base de datos de prueba en lugar de su base de datos de producción.
Esto es útil de varias maneras:
· Cuando estás escribiendo unidad pruebas de cómo actúan sus vistas con ciertos datos de aparatos, puede
utilizan el servidor de pruebas para interactuar con las vistas en un navegador web, manualmente.
· Supongamos que está desarrollando su aplicación Django y tiene una copia "prístina" de una
base de datos con la que le gustaría interactuar. Puede volcar su base de datos a un accesorio
(utilizando la datos de volcado comando, explicado anteriormente), luego use servidor de pruebas para ejecutar su Web
aplicación con esos datos. Con este arreglo, tienes la flexibilidad de jugar
sus datos de cualquier manera, sabiendo que cualquier cambio de datos que esté haciendo solo se está
hecho a una base de datos de prueba.
Tenga en cuenta que este servidor no no detectar automáticamente los cambios en su código fuente de Python (como
runserver lo hace). Sin embargo, detecta cambios en las plantillas.
--addrport [Puerto número or ipaddr: puerto]
Uso --addrport para especificar un puerto diferente, o dirección IP y puerto, del predeterminado de
127.0.0.1:8000. Este valor sigue exactamente el mismo formato y sirve exactamente lo mismo
funcionar como el argumento de la runserver mando.
Ejemplos:
Para ejecutar el servidor de prueba en el puerto 7000 con accesorio1 y accesorio2:
django-admin testerver --addrport 7000 accesorio1 accesorio2
django-admin servidor de prueba accesorio1 accesorio2 --addrport 7000
(Las declaraciones anteriores son equivalentes. Incluimos ambas para demostrar que
no importa si las opciones vienen antes o después de los argumentos del dispositivo).
Para ejecutar en 1.2.3.4:7000 con un test accesorio:
django-admin servidor de pruebas --addrport 1.2.3.4:7000 prueba
El --sin entrada se puede proporcionar la opción para suprimir todas las indicaciones del usuario.
validar
administrador-django validar
En desuso desde la versión 1.7: Reemplazado por el comprobar mando.
Valida todos los modelos instalados (según el APLICACIONES_INSTALADAS ajuste) e impresiones
errores de validación a la salida estándar.
COMANDOS PREVISTO BY APLICACIONES
Algunos comandos solo están disponibles cuando el django.contrib aplicación que implementos ellos
ha sido facilita. Esta sección los describe agrupados por su aplicación.
django.contrib.auth
cambio de contraseña
administrador-django cambio de contraseña
Este comando solo está disponible si Django autenticación te (django.contrib.auth) es
instalado.
Permite cambiar la contraseña de un usuario. Te pide que ingreses dos veces la contraseña del usuario
dado como parámetro. Si ambos coinciden, la nueva contraseña se cambiará inmediatamente. Si
no proporciona un usuario, el comando intentará cambiar la contraseña cuyo nombre de usuario
coincide con el usuario actual.
Ingrese al --base de datos opción para especificar la base de datos para consultar por el usuario. si no es
proporcionado, Django usará el tu préstamo estudiantil base de datos.
Ejemplo de uso:
django-admin cambiar contraseña ringo
crea superusuario
administrador-django crea superusuario
Este comando solo está disponible si Django autenticación te (django.contrib.auth) es
instalado.
Crea una cuenta de superusuario (un usuario que tiene todos los permisos). Esto es útil si necesita
para crear una cuenta de superusuario inicial o si necesita generar mediante programación
cuentas de superusuario para su(s) sitio(s).
Cuando se ejecuta de forma interactiva, este comando solicitará una contraseña para el nuevo superusuario
cuenta. Cuando se ejecuta de forma no interactiva, no se establecerá ninguna contraseña y la cuenta de superusuario
no podrá iniciar sesión hasta que se haya configurado manualmente una contraseña.
--nombre de usuario
El nombre de usuario y la dirección de correo electrónico de la nueva cuenta se pueden proporcionar mediante el --nombre de usuario
y --Email argumentos en la línea de comando. Si alguno de los dos no se suministra,
crea superusuario lo solicitará cuando se ejecute de forma interactiva.
Ingrese al --base de datos Opción para especificar la base de datos en la que se incluirá el objeto de superusuario.
salvado.
Puede subclasificar el comando de administración y anular get_input_data () si quieres
personalizar la entrada y validación de datos. Consulte el código fuente para obtener detalles sobre el existente
implementación y los parámetros del método. Por ejemplo, podría ser útil si tiene un
Clave externa in CAMPOS REQUERIDOS y desea permitir la creación de una instancia en lugar de ingresar
la clave principal de una instancia existente.
django.contrib.gis
Inspeccionar
Este comando solo está disponible si geodjango (django.contrib.gis) esta instalado.
Por favor refiérase a su descripción en la documentación de GeoDjango.
django.contrib.sesiones
sesiones claras
administrador-django sesiones claras
Se puede ejecutar como un trabajo cron o directamente para limpiar las sesiones caducadas.
django.contrib.mapas del sitio
ping_google
Este comando solo está disponible si el Sitemaps marco (django.contrib.mapas del sitio) es
instalado.
Por favor refiérase a su descripción en la documentación de Sitemaps.
django.contrib.archivos estáticos
coleccionista
Este comando solo está disponible si el estático archivos solicitud en línea.
(django.contrib.archivos estáticos) esta instalado.
Por favor refiérase a su descripción existentes archivos estáticos documentación.
encontrar estático
Este comando solo está disponible si el estático archivos solicitud en línea.
(django.contrib.archivos estáticos) esta instalado.
Por favor refiérase a su descripción existentes archivos estáticos documentación.
DEFAULT CAMPUS
Aunque algunos comandos pueden permitir sus propias opciones personalizadas, cada comando permite la
siguientes opciones:
--pythonpath
Ejemplo de uso:
django-admin migre --pythonpath='/home/djangoprojects/myproject'
Agrega la ruta del sistema de archivos dada a Python importar Buscar camino. Si esto no se proporciona,
administrador-django utilizará el PITONPATO Variable ambiental.
Tenga en cuenta que esta opción es innecesaria en manage.py, porque se encarga de configurar el
Ruta de Python para ti.
- ajustes
Ejemplo de uso:
django-admin migre --settings=mysite.settings
Especifica explícitamente el módulo de configuración que se va a usar. El módulo de configuración debe estar en Python
sintaxis del paquete, por ejemplo configuración.misitio. Si esto no se proporciona, administrador-django utilizará el
DJANGO_SETTINGS_MODULE Variable ambiental.
Tenga en cuenta que esta opción es innecesaria en manage.py, porque usa settings.py del desplegable
proyecto actual por defecto.
--rastrear
Ejemplo de uso:
Django-admin migre --traceback
De forma predeterminada, administrador-django mostrará un mensaje de error simple cada vez que un Error de comando ocurre,
pero un seguimiento de pila completo para cualquier otra excepción. si especificas --rastrear, administrador-django
también generará un seguimiento de pila completo cuando un Error de comando es elevado.
--verbosidad
Ejemplo de uso:
django-admin migre --verbosidad 2
Uso --verbosidad para especificar la cantidad de notificación e información de depuración que
administrador-django debe imprimir en la consola.
· 0 significa que no hay salida.
· 1 significa salida normal (predeterminado).
· 2 significa salida detallada.
· 3 significa muy salida detallada.
--sin color
Ejemplo de uso:
django-admin sqlall --sin color
De forma predeterminada, administrador-django formateará la salida para colorearla. Por ejemplo, los errores
se imprimirá en la consola en rojo y las declaraciones SQL se resaltarán sintaxis. Para prevenir
esto y tener una salida de texto sin formato, pase el --sin color opción al ejecutar su comando.
COMÚN CAMPUS
Las siguientes opciones no están disponibles en todos los comandos, pero son comunes a un número
de comandos.
--base de datos
Se utiliza para especificar la base de datos en la que operará un comando. Si no se especifica, este
la opción por defecto será un alias de tu préstamo estudiantil.
Por ejemplo, para volcar datos de la base de datos con el alias dominar:
django-admin dumpdata --database = maestro
--excluir
Excluye una aplicación específica de las aplicaciones cuyo contenido se emite. Para
ejemplo, para excluir específicamente la auth aplicación desde la salida de dumpdata, usted
Llamaría:
django-admin volcado de datos --excluir=autorización
Si desea excluir múltiples aplicaciones, use múltiples --excluir directivas:
django-admin dumpdata --exclude = auth --exclude = contenttypes
--lugar
Ingrese al --lugar or -l opción para especificar la configuración regional para procesar. Si no se proporciona todo
se procesan los locales.
--sin entrada
Ingrese al --sin entrada opción para suprimir todos los mensajes de usuario, como "¿Está seguro?"
mensajes de confirmación. Esto es útil si administrador-django se está ejecutando como un desatendido,
guión automatizado.
EXTRA DELICIAS
Sintaxis colorante
El administrador-django / manage.py Los comandos usarán una salida bastante codificada por colores si su terminal
admite salida en color ANSI. No usará los códigos de color si está canalizando el comando
salida a otro programa.
En Windows, la consola nativa no admite secuencias de escape ANSI, por lo que de forma predeterminada
no hay salida de color. Pero puedes instalar el ANSICON herramienta de terceros, Django
Los comandos detectarán su presencia y harán uso de sus servicios para colorear la salida solo
como en las plataformas basadas en Unix.
Los colores utilizados para el resaltado de sintaxis se pueden personalizar. Django se envía con tres colores.
paletas:
· oscuro, adecuado para terminales que muestran texto blanco sobre fondo negro. Este es el
paleta predeterminada.
· luz, adecuado para terminales que muestran texto negro sobre fondo blanco.
· sin color, que deshabilita el resaltado de sintaxis.
Una paleta se selecciona configurando un DJANGO_COLORS variable de entorno para especificar el
paleta que desea utilizar. Por ejemplo, para especificar el luz paleta bajo Unix u OS/X
BASH shell, ejecutaría lo siguiente en un símbolo del sistema:
exportar DJANGO_COLORS="luz"
También puede personalizar los colores que se utilizan. Django especifica una serie de roles en
que color se usa:
· error - Un gran error.
· para - Un error menor.
· campo_sql - El nombre de un campo modelo en SQL.
· tipo_sql_col - El tipo de un campo de modelo en SQL.
· palabra_clave_sql - Una palabra clave de SQL.
· tabla_sql - El nombre de un modelo en SQL.
· http_info - Una respuesta del servidor informativo HTTP 1XX.
· http_éxito - Una respuesta del servidor 2XX HTTP Success.
· http_no_modificado - Una respuesta del servidor 304 HTTP no modificado.
· http_redirect - Una respuesta del servidor de redireccionamiento HTTP 3XX distinta de 304.
· http_no_encontrado - Una respuesta del servidor 404 HTTP No encontrado.
· http_bad_request - Una respuesta del servidor de solicitud incorrecta HTTP 4XX que no sea 404.
· http_error_servidor - Una respuesta de error del servidor HTTP 5XX.
A cada uno de estos roles se le puede asignar un color frontal y de fondo específico, desde el
Lista de seguidores:
· negro
· rojo
· green
· amarillo
· azul
· magenta
· cian
· complejo de salvador blanco
Cada uno de estos colores se puede modificar utilizando las siguientes opciones de visualización:
·
· guion bajo
· parpadear
· marcha atrás
· ocultar
Una especificación de color sigue uno de los siguientes patrones:
· rol=fg
· rol=fg/bg
· role = fg, opción, opción
· role = fg / bg, opción, opción
donde papel es el nombre de un rol de color válido, fg es el color de primer plano, bg son los
color de fondo y cada uno opción es una de las opciones de modificación de color. Múltiples colores
las especificaciones se separan luego por punto y coma. Por ejemplo:
export DJANGO_COLORS="error=amarillo/azul, parpadeo;aviso=magenta"
especificaría que los errores se muestren con amarillo parpadeante sobre azul, y avisos
se muestra usando magenta. Todos los demás roles de color se dejarían sin colorear.
Los colores también se pueden especificar ampliando una paleta base. Si pones un nombre de paleta en un
especificación de color, se cargarán todos los colores implícitos en esa paleta. Entonces:
exportar DJANGO_COLORS="luz;error=amarillo/azul, parpadeo;aviso=magenta"
especificaría el uso de todos los colores en la paleta de colores claros, excepto por los colores
para errores y avisos que se anularían según lo especificado.
Soporte para salida codificada por colores desde administrador-django / manage.py utilidades en Windows por
Confiar en la aplicación ANSICON se agregó en Django 1.7.
Comandos de Bash terminación
Si usa el shell Bash, considere instalar el script de finalización de bash de Django, que
vive en extras/django_bash_completion en la distribución de Django. Permite
finalización de tabulación de administrador-django y manage.py comandos, para que pueda, por ejemplo ...
· Escribe administrador-django.
· Presione [TAB] para ver todas las opciones disponibles.
· Escribe sql, luego [TAB], para ver todas las opciones disponibles cuyos nombres comienzan con sql.
See /howto/comandos-de-administración-personalizada para saber cómo agregar acciones personalizadas.
django.core.management.call_command (nombre, * argumentos, ** opciones)
Para llamar a un comando de administración desde el uso del código llamada_comando.
nombre el nombre del comando a llamar.
* argumentos una lista de argumentos aceptados por el comando.
** opciones
opciones nombradas aceptadas en la línea de comandos.
Ejemplos:
desde la gestión de importación de django.core
management.call_command('vaciar', verbosidad=0, interactivo=Falso)
management.call_command('loaddata', 'test_data', verbosidad=0)
Tenga en cuenta que las opciones de comando que no toman argumentos se pasan como palabras clave con ¿Editas con tu equipo de forma remota? or
Falso, como se puede ver con el interactivo Opción anterior.
Los argumentos con nombre se pueden pasar usando cualquiera de las siguientes sintaxis:
# Similar a la línea de comando
management.call_command ('dumpdata', '--natural-Foreign')
# Argumento con nombre similar a la línea de comando menos los guiones iniciales y
# con guiones internos reemplazados por guiones bajos
gestión.call_command('dumpdata', natural_foreign=True)
# `use_natural_foreign_keys` es la variable de destino de la opción
management.call_command ('dumpdata', use_natural_foreign_keys = True)
La primera sintaxis ahora es compatible gracias a los comandos de administración que utilizan el argumentar módulo.
Para la segunda sintaxis, Django previamente pasó el nombre de la opción tal cual al comando, ahora
siempre está usando el dest nombre de la variable (que puede o no ser el mismo que la opción
nombre).
Las opciones de comando que toman múltiples opciones se pasan a una lista:
management.call_command ('dumpdata', exclude = ['contenttypes', 'auth'])
SALIDA REDIRECCION
Tenga en cuenta que puede redirigir la salida estándar y los flujos de error, ya que todos los comandos admiten el
stdout y stderr opciones Por ejemplo, podrías escribir:
con open ('/ tmp / command_output') como f:
gestión.call_command('dumpdata', stdout=f)
Use django-admin en línea usando los servicios de onworks.net
