Puedo utilizar una vista de base de datos como un modelo en Django?

Question

me gustaría utilizar una vista que he creado en mi base de datos como fuente para mi django-vista.

Es esto posible, sin el uso de sql personalizada?

******13/02/09 ACTUALIZACIÓN***********

Como muchas de las respuestas sugieren, puedes hacer tu propio punto de vista en la base de datos y, a continuación, utilizarlo dentro de la API por definición en models.py.

algunos de advertencia, sin embargo:

• manage.py syncdb ya no funcionará
• la vista de la necesidad de la misma cosa, al inicio de su nombre, como todos los otros modelos(tablas) e.g si la aplicación se llama "cosa", entonces su vista se necesitan para ser llamado thing_$viewname

Answer 1

Desde Django 1.1, puede utilizar Options.managed para eso.

En versiones anteriores, se puede definir fácilmente una clase de modelo para una vista y usarlo como sus otros puntos de vista. Acabo de probar que el uso de una aplicación basada en SQLite y parece que funciona bien. Sólo asegúrese de añadir un campo de clave principal si la columna "clave principal" de su punto de vista no es nombrado 'id' y especifique el nombre de la vista en las opciones Meta si su vista no se llama 'app_classname'.

El único problema es que el comando "syncdb" elevará una excepción, ya Django tratará de crear la tabla. Puede evitar que al definir los 'modelos de vista' en un archivo de Python independiente, diferente de models.py. De esta manera, Django no verlos cuando introspección models.py para determinar los modelos para crear la aplicación y por lo tanto no intentará crear la tabla.

Answer 2

Sólo una actualización para aquellos que vas a encontrar a esta pregunta (de Google o cualquier otra cosa)...

Actualmente Django tiene una simple "manera adecuada" para definir el modelo sin la gestión de tablas de base de datos:

Opciones.administrado

Por defecto True, significado de Django va a crear las tablas de base de datos en syncdb y eliminar como parte de un reset comandos de administración.Es decir, Django gestiona las tablas de base de datos' de los ciclos de vida.

Si False, no hay tabla de base de datos la creación o eliminación de las operaciones serán realizadas para este modelo.Esto es útil si el modelo representa una tabla o una vista de base de datos que ha sido creado por algún otro medio.Este es el sólo diferencia cuando managed es False.Todos los demás aspectos del modelo de manejo son exactamente el mismo que el normal.

Answer 3

I Sólo se aplicó un modelo utilizando una vista con postgres 9.4 y Django 1.8.

He creado clases de migración personalizados como este:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations


class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0002_previousdependency'),
    ]

    sql = """
    create VIEW myapp_myview as
     select your view here
    """

    operations = [
        migrations.RunSQL("drop view if exists myapp_myview;"),
        migrations.RunSQL(sql)
    ]

escribí el modelo como lo haría normalmente. Funciona para mis propósitos.

Nota: -. Cuando me encontré con makemigrations un nuevo archivo de migración fue creado para el modelo, que he eliminado manualmente

completa revelación- mi punto de vista es de sólo lectura porque estoy utilizando una vista derivada de un tipo de datos jsonb y no he escrito una actualización de las reglas en lugar.

Answer 4

Lo hemos hecho bastante extensamente en nuestras aplicaciones con MySQL para evitar la limitación única base de datos de Django. Nuestra aplicación tiene un par de bases de datos que viven en una sola instancia de MySQL. Podemos lograr modelo de base de datos cruzada se une de esta manera el tiempo que tenemos vistas creadas para cada tabla en la base de datos "actual".

En cuanto a las inserciones / actualizaciones en vistas van, con nuestros casos de uso, una vista es básicamente un "SELECT * FROM [db.table];". En otras palabras, no hacemos ningún complejo se une o filtrado para insertar / actualizaciones disparan desde save () funcionan bien. Si su caso de uso requiere tan complejo une amplia filtrado o, sospecho que no tendrá ningún problema para escenarios de sólo lectura, pero puede que tenga problemas de inserción / actualización. Creo que hay algunas limitaciones subyacentes en MySQL que le impiden la actualización de vistas en que se cruzan las tablas, tiene filtros complejos, etc.

De todos modos, su kilometraje puede variar si se está utilizando un RDBMS distinto a MySQL, pero Django no le importa si su sentado encima de una mesa física o vista. Va a ser el RDBMS que determina si realmente funciona como se espera. Como señaló un comentarista anterior, es probable que estar tirando syncdb hacia fuera de la ventana, aunque hemos trabajado con éxito a su alrededor con una señal post-syncdb que elimina la tabla física creado por Django y dirige nuestra "... crear la vista" de comandos. Sin embargo, la señal post-syncdb es un poco esotérico en la forma en que se desencadena, por lo caveat emptor allí también.

EDIT: Por supuesto, por "señal post-syncdb" quiero decir "post-syncdb oyente"

Answer 5

Django Documentación Oficial , se puede llamar a la vista como esta:

#import library
from django.db import connection

#Create the cursor
cursor = connection.cursor()

#Write the SQL code
sql_string = 'SELECT * FROM myview'

#Execute the SQL
cursor.execute(sql_string)
result = cursor.fetchall()

Espero que ayuda; -)