문제

데이터베이스에서 만든 뷰를 Django-View의 소스로 사용하고 싶습니다.

사용자 정의 SQL을 사용하지 않고 가능합니까?

****** 13/02/09 업데이트 ***********

많은 답변에서 알 수 있듯이 데이터베이스에서 자신의 시청을 한 다음 Models.py에서 정의하여 API 내에서 사용할 수 있습니다.

그래도 일부 경고 :

  • manage.py syncdb는 더 이상 작동하지 않습니다
  • 보기에는 이름이 시작될 때 다른 모든 모델 (테이블)과 동일한 것이 필요합니다. 예를 들어 앱이 "Thing"이라고 불리는 경우 뷰는 the_ $ viewName이라고 불러야합니다.
도움이 되었습니까?

해결책

Django 1.1이므로 사용할 수 있습니다 옵션. 관리 그에 대한.

이전 버전의 경우보기를 위해 모델 클래스를 쉽게 정의하고 다른보기처럼 사용할 수 있습니다. 방금 sqlite 기반 앱을 사용하여 테스트했는데 잘 작동하는 것 같습니다. View의 "기본 키"열이 'ID'라는 이름이없는 경우 기본 키 필드를 추가하고 뷰가 'APP_ClassName'이라고 불리지 않는 경우 메타 옵션에보기 이름을 지정하십시오.

유일한 문제는 Django가 테이블을 만들려고 시도하기 때문에 "SyncDB"명령이 예외를 제기한다는 것입니다. Models.py와는 별도의 Python 파일에서 '보기 모델'을 정의하여이를 방지 할 수 있습니다. 이런 식으로 Django는 INTROSPECTION.PY에서 앱을 위해 생성 할 모델을 결정하기 위해 그것들을 보지 못하면 테이블을 만들려고 시도하지 않습니다.

다른 팁

이 질문에 직면 할 사람들을위한 업데이트 만 (Google 또는 기타 무엇이든) ...

현재 Django는 간단한 "적절한 방법"이 있습니다. 데이터베이스 테이블을 관리하지 않고 모델을 정의하십시오:

옵션. 관리

기본값 True, django가 적절한 데이터베이스 테이블을 생성한다는 의미 syncdb a의 일부로 제거하십시오 reset 관리 명령. 즉, Django입니다 관리 데이터베이스 테이블의 라이프 사이클.

만약에 False,이 모델에는 데이터베이스 테이블 작성 또는 삭제 작업이 수행되지 않습니다. 이는 모델이 기존 테이블 또는 다른 방법으로 생성 된 데이터베이스보기를 나타내는 경우 유용합니다. 이것이 차이 managed ~이다 False. 모델 처리의 다른 모든 측면은 정상과 정확히 동일합니다.

방금 Postgres 9.4 및 Django 1.8의 뷰를 사용하여 모델을 구현했습니다.

다음과 같은 맞춤형 마이그레이션 클래스를 만들었습니다.

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

나는 평소처럼 모델을 썼습니다. 그것은 내 목적을 위해 작동합니다.

메모- MakemiTrations를 실행했을 때 모델에 대한 새 마이그레이션 파일이 생성되었으며 수동으로 삭제했습니다.

전체 공개- JSONB 데이터 유형에서 파생 된 뷰를 사용하고 있으며 대신 업데이트 규칙을 작성하지 않았기 때문에 내보기 만 읽습니다.

우리는 Django의 단일 데이터베이스 제한을 해결하기 위해 MySQL을 사용하여 응용 프로그램에서이를 매우 광범위하게 수행했습니다. 우리의 응용 프로그램에는 단일 MySQL 인스턴스에있는 몇 개의 데이터베이스가 있습니다. "현재"데이터베이스에서 각 테이블에 대한 뷰를 만들어 보는 한 크로스-데이터베이스 모델 이이 방식으로 결합 할 수 있습니다.

삽입/업데이트가 진행되는 한, 사용 사례와 함께보기는 기본적으로 [db.table]에서"select * "입니다. 다시 말해, 우리는 복잡한 조인 또는 필터링을 수행하지 않으므로 save ()에서 삽입/업데이트 트리거가 잘 작동합니다. 유스 케이스에 이러한 복잡한 조인 또는 광범위한 필터링이 필요한 경우 읽기 전용 시나리오에 문제가 없지만 삽입/업데이트 문제가 발생할 수 있습니다. MySQL에는 테이블을 교차 테이블, 복잡한 필터를 가지고있는 견해로 업데이트하지 못하게하는 몇 가지 기본 제약이 있다고 생각합니다.

어쨌든 MySQL 이외의 RDBM을 사용하는 경우 마일리지가 다를 수 있지만 Django는 실제 테이블이나보기 위에 앉아 있는지 신경 쓰지 않습니다. RDBM이 실제로 예상대로 작동하는지 여부를 결정하는 RDBMS가 될 것입니다. 이전의 주석가가 지적했듯이, 당신은 창 밖으로 syncdb를 던질 것입니다. 그러나 우리는 django에 의해 생성 된 물리적 테이블을 삭제하고 "Create View ..."명령을 실행하는 SYNCDB 사후 신호로 성공적으로 작업했습니다. 그러나 SYNCDB 이후 신호는 트리거되는 방식에 약간 난해하므로 경고가 있어야합니다.

편집 : 물론 "Post-Syncdb Signal"에 의해 "SyncDB Post-SyncDB 청취자"를 의미합니다.

에서 장고 공식 문서, 당신은 다음과 같은 견해를 호출 할 수 있습니다.

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

도움이되기를 바랍니다 ;-)

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top