tipos - ¿Puedo usar una vista de base de datos como modelo en Django?

tipos de campos django

Question

Me gustaría usar una vista que he creado en mi base de datos como fuente para mi django-view.

¿Es esto posible, sin usar sql personalizado?

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

Como sugieren muchas de las respuestas, puede hacer su propia vista en la base de datos y luego usarla dentro de la API definiéndola en models.py.

alguna advertencia sin embargo:

• manage.py syncdb ya no funcionará
• la vista necesita lo mismo al comienzo de su nombre que todos los demás modelos (tablas); por ejemplo, si su aplicación se llama "cosa", su vista deberá llamarse thing_ $ viewname

Answer 1

Hemos hecho esto bastante extensamente en nuestras aplicaciones con MySQL para evitar la limitación de la base de datos única de Django. Nuestra aplicación tiene un par de bases de datos que viven en una única instancia de MySQL. Podemos lograr combinaciones de modelos de bases de datos cruzadas de esta manera siempre que hayamos creado vistas para cada tabla en la base de datos "actual".

En cuanto a las inserciones / actualizaciones en las vistas, con nuestros casos de uso, una vista es básicamente una "selección * de [db.table];". En otras palabras, no realizamos ninguna combinación compleja ni filtro, así que insertar / actualizar el desencadenador de save () funciona muy bien. Si su caso de uso requiere combinaciones tan complejas o un filtrado extenso, sospecho que no tendrá ningún problema para los escenarios de solo lectura, pero puede encontrarse con problemas de inserción / actualización. Creo que hay algunas restricciones subyacentes en MySQL que le impiden actualizar en vistas que cruzan tablas, tienen filtros complejos, etc.

De todos modos, su millaje puede variar si usa un RDBMS que no sea MySQL, pero a Django realmente no le importa si está sentado encima de una mesa o vista física. Será el RDBMS el que determine si realmente funciona como esperabas. Como señaló un comentarista anterior, probablemente lanzará syncdb por la ventana, aunque lo solucionamos con una señal post-syncdb que elimina la tabla física creada por Django y ejecuta nuestro comando "create view ...". Sin embargo, la señal post-syncdb es un poco esotérica en la forma en que se desencadena, por lo que también debes tener precaución.

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

Answer 2

De la documentación oficial de Django , puedes llamar a la vista de esta manera:

#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 eso ayude ;-)

Answer 3

Solo una actualización para aquellos que se encontrarán con esta pregunta (de Google o de cualquier otra cosa) ...

Actualmente, Django tiene una "forma correcta" simple para definir el modelo sin gestionar las tablas de la base de datos :

Opciones administradas

El valor predeterminado es True , lo que significa que Django creará las tablas de base de datos apropiadas en syncdb y las eliminará como parte de un comando de administración de reset . Es decir, Django gestiona los ciclos de vida de las tablas de la base de datos.

Si es False , no se realizarán operaciones de creación o eliminación de tablas de bases de datos para este modelo. Esto es útil si el modelo representa una tabla existente o una vista de base de datos que ha sido creada por algún otro medio. Esta es la única diferencia cuando se managed es False . Todos los demás aspectos del manejo del modelo son exactamente los mismos que los normales.

Answer 4

Acabo de implementar un modelo usando una vista con postgres 9.4 y django 1.8.

Creé clases de migración personalizadas como esta:

# -*- 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 ejecuté makemigrations, se creó un nuevo archivo de migración para el modelo, que borré manualmente.

Divulgación completa: mi vista es de solo lectura porque estoy usando una vista derivada de un tipo de datos jsonb y no he escrito una regla ON UPDATE INSTEAD.

Answer 5

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

Para versiones anteriores, puede definir fácilmente una clase Model para una vista y usarla como sus otras vistas. Acabo de probarlo usando una aplicación basada en Sqlite y parece funcionar bien. Solo asegúrese de agregar un campo de clave principal si la columna de "clave principal" de su vista no se llama ''id'' y especifique el nombre de la vista en las opciones Meta si su vista no se llama ''nombre_clase_apl''.

El único problema es que el comando "syncdb" generará una excepción ya que Django intentará crear la tabla. Puede evitar eso definiendo los ''modelos de vista'' en un archivo de Python separado, diferente de models.py. De esta forma, Django no los verá cuando introspecta models.py para determinar los modelos a crear para la aplicación y por lo tanto no intentará crear la tabla.