ユーザ用ツール

サイト用ツール


メモ:django

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン前のリビジョン
次のリビジョン
前のリビジョン
メモ:django [2019/05/29 14:34] – [テスト用の内部サーバ起動] Wiki Editorメモ:django [2019/06/05 17:30] (現在) – [app01/app01/urls.py] Wiki Editor
行 44: 行 44:
 起動コマンドでIPアドレスにアサインすることと、設定ファイルの接続許可が両方正しく設定されて、初めて外部から接続できる。うまく起動できれば、http://[IP Address]:8000/でテストサーバに接続され、ロケット打ち上げが表示される。 起動コマンドでIPアドレスにアサインすることと、設定ファイルの接続許可が両方正しく設定されて、初めて外部から接続できる。うまく起動できれば、http://[IP Address]:8000/でテストサーバに接続され、ロケット打ち上げが表示される。
  
 +===== その他の基本設定 =====
 +app01/settings.pyの基本設定
 +
 +言語やタイムゾーンを設定
 +
 +  LANGUAGE_CODE = 'ja'                                                                                                           
 +  TIME_ZONE = 'Japan'
  
 ===== アプリケーションの作成 ===== ===== アプリケーションの作成 =====
行 67: 行 74:
       return HttpResponse("Hello, Django."       return HttpResponse("Hello, Django."
  
-=== app01/report/urls.py ===+==== app01/report/urls.py ====
 URLのディスパッチ設定。アプリケーションレベルのURLはここでディスパッチする。このファイルは、プロジェクトレベルのURLディスパッチにインクルードして使う。アプリケーション作成時には自動作成されない。 URLのディスパッチ設定。アプリケーションレベルのURLはここでディスパッチする。このファイルは、プロジェクトレベルのURLディスパッチにインクルードして使う。アプリケーション作成時には自動作成されない。
  
-urlpatternsにURLとViewの対応を設定する。ここでは「''」でルートディレクトリへのアクセスをviews.pyのindex関数と対応づける。+urlpatternsにURLとViewの対応を設定する。ここでは「%%''%%」でルートディレクトリへのアクセスをviews.pyのindex関数と対応づける。 
   from django.urls import path   from django.urls import path
   from . import views   from . import views
行 78: 行 86:
   ]   ]
  
-=== app01/app01/urls.py ===+==== app01/app01/urls.py ====
 プロジェクトレベルのURLディスパッチ プロジェクトレベルのURLディスパッチ
  
行 93: 行 101:
  
  
-以上を設定すると、http://[IP Address]:8000/report/で「Hello, Django.」が表示される。+以上を設定すると、%%http://[IP Address]:8000/report/%%で「Hello, Django.」が表示される。 
 + 
 + 
 +===== Model ===== 
 +データベースからデータを呼び出したり保存したりする。直接クエリを発行するのではなく、オブジェクトを介して操作。 
 + 
 +==== データベース ==== 
 +開発途中は取りあえずSQLiteを利用する。本番環境ではPostgreSQLなりMySQLに切り替える。データベースの定義はDjangoが自動的に生成してくれるので、バックエンドはあまり意識する必要はない。とりあえず、設定ファイルだけ確認しておく。 
 + 
 +app01/app01/settings.py 
 +  DATABASES = { 
 +      'default':
 +          'ENGINE': 'django.db.backends.sqlite3', 
 +          'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), 
 +      } 
 +  } 
 + 
 +標準ではSQLiteが使われる。 
 + 
 +Djangoのフレームワークとして必要なテーブルを作成し準備を整える。 
 + 
 +  $ python manage.py migrate 
 + 
 +設定ファイルを参照し、必要なテーブルをデータベースに生成する。 
 + 
 +初期に必要なテーブルは、settings.pyのINSTALLED_APPに列挙されているフレームワークの組み込みアプリケーションを中心に生成される。自分で作成したアプリケーションでモデルを作成すると、migrateによって必要なテーブルが作成される。 
 + 
 +==== Modelの作成 ==== 
 +モデルの定義を作成する。 
 + 
 +app01/report/models.py 
 + 
 +  from django.db import models 
 +   
 +  class Choice(models.Model): 
 +      categ_code = models.CharField(max_length=10) 
 +      categ = models.CharField(max_length=200) 
 +      hs_code = models.CharField(max_length=10) 
 +      hs = models.CharField(max_length=200) 
 +   
 +      def __str__(self): 
 +          return self.categ + self.hs 
 +   
 +  class Report: 
 +      hs_code = models.ForeignKey(Choice, on_delete=models.PROTECT) 
 +      report_field01 = models.CharField(max_length=1000) 
 +      report_field02 = models.CharField(max_length=1000) 
 +      report_field03 = models.CharField(max_length=1000) 
 +   
 +      def __str__(self): 
 +          return str(hs_code) + self.report_field01 
 +   
 + 
 +1つのテーブルは1つのクラスとして定義される。クラスのサブクラスや変数で様々な挙動が設定できる。最も基本的な設定として、クラスの変数がデータベースに対応する。変数にデータの型や外部キーなどを設定していく。 
 + 
 +クラス内の「__str__」関数は、モデルのオブジェクト表現となる。管理画面で一覧表示するときなどに使われる文字列を定義できる。 
 +==== Modelをフレームワークに認識させる ==== 
 +migrationでテーブルを管理するために、フレームワークに作成したアプリケーションを認識させる必要がある。先に示したsettings.pyのINSTALLED_APPに列挙すればよい。 
 + 
 + 
 +app01/app01/settings.py 
 + 
 +  INSTALLED_APPS = [ 
 +      'report.apps.ReportConfig', 
 +      'django.contrib.admin', 
 +      'django.contrib.auth', 
 +      'django.contrib.contenttypes', 
 +      'django.contrib.sessions', 
 +      'django.contrib.messages', 
 +      'django.contrib.staticfiles', 
 +  ] 
 + 
 +ここで記述するのはアプリケーションのクラス名となる。プロジェクトディレクトリからクラスをたどって記述する。ここでは、reportアプリケーションのapps.pyファイルに定義されているReportConfigクラスとなる。このクラスはstartappでアプリケーションを作成した際に自動的に生成される。 
 + 
 +===== データベースへの反映 ===== 
 +定義したモデルに対応してバックエンドのデータベースを作成する。
  
 +  $ python manage.py makemigrations report
  
 +makemigrationsコマンドでモデルの変更を検出し、migrationの定義ファイルを生成する。ポイントは、この時点でデータベースへの変更は一切行われていない点である。migrationの定義内容は、report/migrations/xxxx.pyに生成される。
  
 +migrationで実行される具体的なSQLを確認する。
  
 +  $ python manage.py sqlmigrate report 0001
  
 +最後の引数はmigrationの定義ファイルのファイル名に対応する。何度もモデルを変更すると、そのたびにmigrationが生成され、履歴が残るようになっているようだ。対象となるファイルのmigration内容を確認するために、ファイルの番号を指定する。
  
 +必要なテールが意図通りに作成されることが確認できれば、再度migrationを行いバックエンドのデータベースに反映させる。
  
 +  $ python manage.py migrate
  
  
  
  
メモ/django.1559108097.txt.bz2 · 最終更新: 2019/05/29 14:34 by Wiki Editor

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki