Kann ich einen Datenbank-View als Modell in Django verwenden?

StackOverflow https://stackoverflow.com/questions/507795

Frage

Ich möchte eine Ansicht verwenden ich in meiner Datenbank als Quelle für meine django-Ansicht erstellt haben.

Ist dies möglich, ohne benutzerdefinierten SQL zu verwenden?

****** 13/02/09 UPDATE ***********

Wie viele der Antworten vorschlagen, können Sie einfach Ihre eigene Sicht in der Datenbank vornehmen und es dann in der API verwenden, indem Sie es in models.py definieren.

einige Warnung aber:

  • manage.py syncdb funktioniert nicht mehr
  • müssen die Ansicht, die die gleiche Sache zu Beginn seines Namens als alle anderen Modelle (Tabellen) beispiels wenn Ihre Anwendung Idee_ $ viewname
    • sein „Ding“ dann Ihrer Ansicht nach müssen genannt genannt wird
War es hilfreich?

Lösung

Da Django 1.1 können Sie a href verwenden <= "https://docs.djangoproject.com/en/1.8/ref/models/options/#django.db.models.Options.managed" rel = "noreferrer „> Options.managed dafür.

Für ältere Versionen können Sie ganz einfach eine Modellklasse für eine Ansicht definieren und wie Ihre andere Ansichten verwenden. Getestet habe ich es nur eine SQLite-basierte App und es scheint gut zu funktionieren. So stellen Sie sicher, dass ein Primärschlüsselfeld, wenn Ihre Sicht der „Primärschlüssel“ Spalte hinzuzufügen ist nicht ‚id‘ genannt und die Ansicht der Namen in den Meta-Optionen angeben, wenn Ihre Sicht heißt nicht ‚app_classname‘.

Das einzige Problem ist, dass der „syncdb“ Befehl wird eine Ausnahme ausgelöst, da Django wird versuchen, die Tabelle zu erstellen. Sie können dies verhindern, indem Sie die ‚Ansicht Modelle‘ in einer separaten Python-Datei definiert, anders als models.py. Auf diese Weise wird Django sie nicht sehen, wenn models.py introspecting die Modelle zu bestimmen, für die App erstellen und dafür wird nicht versuchen, die Tabelle zu erstellen.

Andere Tipps

Nur ein Update für diejenigen, die diese Frage (von Google oder was auch immer) begegnen werden ...

Zur Zeit Django hat einen einfachen "richtigen Weg" auf definieren Modell ohne Datenbanktabellen Verwaltung :

  

Options.managed

     

Standardwerte True, Django bedeutet die entsprechenden Datenbanktabellen in syncdb erstellen und entfernen Sie sie als Teil eines reset Management-Befehl. Das heißt, Django schafft die Datenbanktabellen Lifecycles.

     

Wenn False, keine Datenbanktabellenerstellung oder Löschoperationen werden für dieses Modell durchgeführt werden. Dies ist nützlich, wenn das Modell eine vorhandene Tabelle oder einen Datenbank-View darstellt, die durch andere Mittel erstellt wurde. Dies ist der nur Unterschied, wenn managed False ist. Alle anderen Aspekte der Modell Handhabung sind genau die gleichen wie normal.

ich implementiert nur ein Modell eine Ansicht mit Postgres mit 9,4 und django 1.8.

ich benutzerdefinierte Migration Klassen wie folgt erstellt: 

# -*- 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)
    ]

Ich schrieb das Modell, wie ich normalerweise tun würde. Es funktioniert für meine Zwecke.

Hinweis -. Als ich lief makemigrations eine neue Migrationsdatei für das Modell erstellt wurde, die ich manuell gelöscht

Voll disclosure- meiner Ansicht nach nur gelesen wird, weil ich eine Ansicht bin mit von einem jsonb Datentyp abgeleitet und haben nicht eine ON UPDATE STATT Regel geschrieben.

Wir haben dies getan recht ausführlich in unseren Anwendungen mit MySQL um die einzige Datenbank Einschränkung von Django zu arbeiten. Unsere Anwendung hat ein paar Datenbanken in einer einzigen MySQL-Instanz leben. Wir können erreichen Cross-Datenbank-Modell, so lange diese Weise schließt sich, wie wir für jede Tabelle in der „aktuellen“ Datenbank erstellt Ansichten haben.

Soweit Einsätze / Updates in Ansichten gehen, mit unseren Anwendungsfällen ist eine Ansicht im Grunde ein „select * from [db.table];“. Mit anderen Worten, machen wir keine komplexen Joins oder Filterung so einfügen / Updates auslösen von save () gut funktionieren. Wenn Ihr Anwendungsfall so komplex erfordert beitritt oder umfangreiche Filterung, ich vermute, Sie werden keine Probleme haben, für Nur-Lese-Szenarien, können aber in insert / update Probleme laufen. Ich denke, dass es einige zugrunde liegenden Einschränkungen in MySQL, die Sie von der Aktualisierung in Ansichten zu verhindern, die Tabellen durchqueren, haben komplexe Filter, usw.

Wie auch immer, die Leistung kann variieren, wenn Sie ein RDBMS anderen als MySQL verwenden, aber Django nicht wirklich, ob sein auf einer physischen Tabelle oder Ansicht sitzen. Es wird das RDBMS, das festlegt, ob es tatsächlich funktioniert wie erwartet. Wie der vorherige Kommentator erwähnt, werden Sie wahrscheinlich syncdb aus dem Fenster werfen, obwohl wir erfolgreich um es mit einem Post-syncdb Signal gearbeitet, die die physische Tabelle von Django erstellt fallen und laufen unseren „Ansicht erstellen ...“ Befehl. Allerdings ist die Post-syncdb Signal ist ein bisschen esoterisch in der Art und Weise es ausgelöst wird, so caveat emptor auch dort.

EDIT: Natürlich von "post-syncdb Signal" Ich meine "post-syncdb Hörer"

Django Offizielle Dokumentation könnten Sie die Ansicht wie folgt aufrufen: 

#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()

Hoffe, es hilft; -)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top