-
Notifications
You must be signed in to change notification settings - Fork 7
Expand file tree
/
Copy pathchap05.xml
More file actions
2622 lines (2335 loc) · 117 KB
/
chap05.xml
File metadata and controls
2622 lines (2335 loc) · 117 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[
<!ENTITY BASEID "djangobook.chap05">
]>
<chapter lang="ru" id="&BASEID;">
<title id="&BASEID;.title">
Модели
</title>
<para>
Перевод © Попов Руслан <ruslan.popov • gmail>
</para>
<para>
В главе <quote><xref linkend="djangobook.chap03"
endterm="djangobook.chap03.title"/></quote> мы описали основы
создания динамических сайтов с помощью Django: настройка
представлений и схемы URL для них. Как было рассказано,
представление отвечает за <emphasis>некоторую произвольную
логику</emphasis> и возвращает отклик. В одном из примеров логикой
являлось вычисление текущей даты и времени.
</para>
<para>
В современных веб-приложениях произвольная логика часто вовлечена
в работу с базой данных. Обычно, сайт такого типа подключается к
серверу базы данных, получает от него некоторые данные и, выполнив
форматирование, отображает эти данные на странице. Так же сайт
может предоставлять посетителям сайта возможность заполнять базу
данных своими данными.
</para>
<para>
Множество сложных сайтов предоставляют некую комбинацию этих двух
вариантов. Например, <ulink url="http://www.amazon.com/"/>
является отличным примером такого сайта. Каждая страница продукта,
по существу, является запросом в базу данных продуктов Amazon,
отформатированном в виде HTML. А когда вы отсылаете свой
комментарий, он помещается в базу данных отзывов.
</para>
<para>
Django отлично подходит для создания сайтов, ориентированных на
использование совместно с базой данных, т.к., она поставляется с
простыми, но мощными механизмами выполнения запросов к базе данных
с помощью Python. Эта глава описывает этот механизм: слой Django
для работы с базой данных.
</para>
<para>
Следует отметить, что необязательно знать основы теории баз данных
и SQL для использования этого слоя Django, но это крайне
рекомендуется. Введение в эти понятия находится вне сферы этой
книги. Вероятно, вы сможете понять концепции, учитывая контекст
изложения.
</para>
<section id="&BASEID;.dumbway">
<title id="&BASEID;.dumbway.title">
<quote>Тупой</quote> способ выполнения запросов в представлениях
</title>
<para>
Подобно определённому в главе <quote><xref
linkend="djangobook.chap03"
endterm="djangobook.chap03.title"/></quote>
<quote>тупому</quote> способу генерации вывода с помощью
представлений (вбивание руками текста прямо в код
представления), существует <quote>тупой</quote> способ
получения в представлениях информации из базы данных. Это
просто: используйте <emphasis>любую</emphasis> существующую
библиотеку языка Python для выполнения SQL запроса и
обрабатывайте его результаты.
</para>
<para>
В этом примере представления мы используем библиотеку
<token>MySQLdb</token> (доступную по адресу <ulink
url="http://www.djangoproject.com/r/python-mysql/"/>) для
подключения к базе данных MySQL, получения нескольких записей и
помещения их в шаблон для отображения на странице сайта:
<screen>
<![CDATA[
from django.shortcuts import render_to_response
import MySQLdb
def book_list(request):
db = MySQLdb.connect(user='me', db='mydb', passwd='secret', host='localhost')
cursor = db.cursor()
cursor.execute('SELECT name FROM books ORDER BY name')
names = [row[0] for row in cursor.fetchall()]
db.close()
return render_to_response('book_list.html', {'names': names})
]]>
</screen>
</para>
<para>
Такой подход работает, но вы должны немедленно столкнуться с
некоторыми проблемами:
<itemizedlist>
<listitem>
<para>
Мы жёстко определяем параметры соединения с базой
данных. В идеале эти параметры должны храниться в
конфигурации проекта Django.
</para>
</listitem>
<listitem>
<para>
Мы должны писать нудный код: создать соединение, создать
курсор, выполнить оператор и закрыть соединение. В идеале
всё, что мы должны сделать — указать необходимый нам
результат.
</para>
</listitem>
<listitem>
<para>
Это привязывает нас к MySQL. Если, с течением времени, мы
решим перейти с MySQL на PostgreSQL, нам потребуется
использовать другой драйвер для базы данных (т.е.,
<token>psycopg</token> вместо <token>MySQLdb</token>),
изменить параметры соединения и, в зависимости от природы
SQL операторов, возможно, переписать SQL запросы. В
идеале, мы должны рассматривать сервер базы данных
абстрактно, т.е., для смены сервера мы должны внести
изменения в одно только место проекта. (Эта проблема имеет
особое значение в случае, если вы работаете над
приложением Django с открытым кодом, которое вы желаете
распространить среди максимально возможного количества
пользователей.)
</para>
</listitem>
</itemizedlist>
</para>
<para>
Как вы можете ожидать, слой Django для работы с базами данных
помогает решать такие проблемы. Далее представлен пример как
надо изменить предыдущее представление для использования Django
API для работы с базами данных:
<screen>
<![CDATA[
from django.shortcuts import render_to_response
from mysite.books.models import Book
def book_list(request):
books = Book.objects.order_by('name')
return render_to_response('book_list.html', {'books': books})
]]>
</screen>
</para>
<para>
Мы разберём этот код немного позже в этой главе.
</para>
</section>
<section id="&BASEID;.mtvdevpat">
<title id="&BASEID;.mtvdevpat.title">
Методика MTV (или MVC)
</title>
<para>
Прежде чем мы погрузимся в изучение кода, давайте рассмотрим
общий дизайн БД ориентированных веб-приложений Django.
</para>
<para>
Как мы рассказывали в предыдущих главах, Django поощряет
свободное связывание и строгое разделение частей
приложения. Если следовать этой философии, то легко вносить
изменения в одну конкретную часть приложения без ущерба для
остальных частей. В функциях представления, например, мы
обсуждали важность отделения бизнес-логики от логики отображения
с помощью шаблонной системы. Используя слой для работы с базой
данных, мы применяем эту же философию для логики доступа к
данным.
</para>
<para>
Эти три вещи вместе — логика доступа к данным,
бизнес-логика и логика отображения — составляют концепцию,
которую называют шаблоном
<emphasis>Модель-Представление-Управление</emphasis>
(<emphasis>Model-View-Controller</emphasis>, MVC) архитектуры
программного обеспечения. В этой концепции термин
<quote>Модель</quote> относится к логике доступа к данным;
термин <quote>Представление</quote> относится к той части
системы, которая определяет, что показать и как; а термин
<quote>Управление</quote> относится к той части системы, которая
определяет какое представление надо использовать, в зависимости
от пользовательского ввода, по необходимости получая доступ к
модели.
</para>
<para>
<note>
<title>
Почему используется сокращение?
</title>
<para>
Целью чёткого определения сокращений, подобных MVC, является
упорядочивание взаимодействия между разработчиками. Вместо
того, чтобы сказать вашим сотрудникам: <quote>Давайте
использовать абстрактный доступ к данным, затем создадим
слой управления отображением данных и тогда создадим слой
между ними, который всем этим управляет</quote> можно
воспользоваться общим термином: <quote>Давайте здесь
использовать подход MVC</quote>.
</para>
</note>
</para>
<para>
Django следует модели MVC достаточно близко, т.е., может быть
назван MVC совместимой средой разработки. Вот примерно как M, V
и C используются в Django:
<itemizedlist>
<listitem>
<para>
<emphasis>M</emphasis>, доступ к данным, обрабатывается
слоем работы с базой данных, который описан в этой главе.
</para>
</listitem>
<listitem>
<para>
<emphasis>V</emphasis>, эта часть, которая определяет
какие данные получать и как их отображать, обрабатывается
представлениями и шаблонами.
</para>
</listitem>
<listitem>
<para>
<emphasis>C</emphasis>, эта часть, которая выбирает
представление в зависимости от пользовательского ввода,
обрабатывается самой средой разработки, следуя созданной
вами схемой URL, и вызывает соответствующую функцию Python
для указанного URL.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Так как <quote>C</quote> обрабатывается средой разработки и всё
интересное в Django происходит в моделях, шаблонах и
представлениях, на Django ссылаются как на
<emphasis>MTV-ориентированную среду разработки</emphasis>. В
MTV-подходе к разработке:
<itemizedlist>
<listitem>
<para>
<emphasis>M</emphasis> определено для
<quote>Модели</quote> (Model), слоя доступа к данным. Этот
слой знает всё о данных: как получить к ним доступ, как
проверить их, как с ними работать и как данные связаны
между собой.
</para>
</listitem>
<listitem>
<para>
<emphasis>T</emphasis> определено для
<quote>Шаблона</quote> (Template), слоя представления
данных. Этот слой принимает решения относительно
представления данных: как и что должно отображаться на
странице или в другом типе документа.
</para>
</listitem>
<listitem>
<para>
<emphasis>V</emphasis> определено для
<quote>Представления</quote> (View), слоя
бизнес-логики. Этот слой содержит логику, как получать
доступ к моделям и применять соответствующий шаблон. Вы
можете рассматривать его как мост между моделями и
шаблонами.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Если вам приходилось работать с другими MVC ориентированными
средами разработки, такими как Ruby on Rails, вы можете
рассматривать представления в Django как
<quote>контролёры</quote>, а шаблоны Django — как
<quote>представления</quote>. Это печальная путаница возникла в
результате различных толкований MVC. В интерпретации Django
<quote>представление</quote> описывает данные, которые будут
представлены пользователю. Неважно <emphasis>как</emphasis> эти
данные будут выглядеть, важно <emphasis>какие</emphasis>
данные. Напротив, в Ruby on Rails и подобных ему средах
предполагается, что в работу контролёра включено принятие
решения, какие данные будут представлены пользователю, в то
время как представление точно определяет
<emphasis>как</emphasis> эти данные будут выглядеть, а не
<emphasis>какие</emphasis> данные будут представлены.
</para>
<para>
Ни одна интерпретация не имеет преимуществ над другой. Важно
понимать основную концепцию.
</para>
</section>
<section id="&BASEID;.dbconfig">
<title id="&BASEID;.dbconfig.title">
Настройка базы данных
</title>
<para>
Учитывая вышеописанную философию, начнём исследовать слой Django
для работы с базой данных. Первое, что нам понадобится —
необходимо позаботиться о начальной настройке. Необходимо
указать Django какой сервер базы данных использовать и как к
нему подключаться.
</para>
<para>
<note>
<title>
Используем кодировку UTF-8, пример для MySQL
(прим. переводчика)
</title>
<para>
Откроем на редактирование файл
<filename>/etc/mysql/my.cnf</filename>.
</para>
<para>
В конец секции <token>[client]</token> добавим строчку:
<screen>
default-character-set=utf8
</screen>
</para>
<para>
В конец секции <token>[mysqld]</token> добавим строчки:
<screen>
default-character-set=utf8
collation_server=utf8_unicode_ci
</screen>
</para>
<para>
Теперь следует перезапустить сервер базы данных и можно
приступать к созданию самой базы.
</para>
</note>
</para>
<para>
<note>
<title>
Проверка настроек кодировки (прим. переводчика)
</title>
<para>
В результате вышеописанных действий вы должны получить:
<screen>
<![CDATA[
mysql> show variables like 'coll%';
+----------------------+-----------------+
| Variable_name | Value |
+----------------------+-----------------+
| collation_connection | utf8_general_ci |
| collation_database | utf8_unicode_ci |
| collation_server | utf8_unicode_ci |
+----------------------+-----------------+
3 rows in set (0.00 sec)
mysql> show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)
]]>
</screen>
</para>
</note>
</para>
<para>
Мы предполагаем, что вы уже установили сервер базы данных,
запустили его и создали базу данных внутри. Пример для MySQL:
<screen>
<![CDATA[
CREATE USER user@localhost IDENTIFIED BY "topsecret";
CREATE DATABASE mysite;
GRANT ALL ON mysite.* TO user@localhost;
]]>
</screen>
</para>
<para>
Использование SQLite является особым случаем: не требуется
создавать базу данных, так как SQLite использует файлы на
файловой системе для хранения своих данных.
</para>
<para>
Подобно параметру <varname>TEMPLATE_DIRS</varname> из предыдущей
главы, по умолчанию параметры соединения с базами данных
определяются в файле конфигурации проекта,
<filename>settings.py</filename>, опцией <varname>DATABASES</varname>,
которая по-умолчанию равна <token>{}</token>. База <token>default</token>
должна быть определена обязательно. Так ж словарь может определять любое
количество других баз данных. Самый простой вариант, это использование одной
базы данных SQLite:
<screen>
<![CDATA[
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'mydatabase'
}
}
]]>
</screen>
</para>
<para>
Для других баз данных необходимо больше параметров. Рассмотрим каждый параметр.
<itemizedlist>
<listitem>
<para>
Параметр <varname>ENGINE</varname> указывает тип
базы данных. Может быть одним из показанных в таблице
<quote><xref linkend="&BASEID;.tbl1"
endterm="&BASEID;.tbl1.title"/></quote>.
</para>
<para>
<table id="&BASEID;.tbl1" frame="all" pgwide="1">
<title id="&BASEID;.tbl1.title">
Настройки драйвера базы данных
</title>
<tgroup cols="3" align="left" colsep="1" rowsep="1">
<colspec colname="c1" colwidth="4cm"/>
<colspec colname="c2" colwidth="4cm"/>
<colspec colname="c3" colwidth="6cm"/>
<thead>
<row>
<entry>Значение</entry>
<entry>База данных</entry>
<entry>Драйвер</entry>
</row>
</thead>
<tbody>
<row>
<entry><token>django.db.backends.postgresql</token></entry>
<entry>PostgreSQL</entry>
<entry>
<token>psycopg</token> версия 1.х, <ulink
url="http://www.djangoproject.com/r/python-pgsql/1/"/>
</entry>
</row>
<row>
<entry><token>django.db.backends.postgresql_psycopg2</token></entry>
<entry>PostgreSQL</entry>
<entry>
<token>psycopg</token> версия 2.х, <ulink
url="http://www.djangoproject.com/r/python-pgsql/"/>
</entry>
</row>
<row>
<entry><token>django.db.backends.mysql</token></entry>
<entry>MySQL</entry>
<entry>
<token>MySQLdb</token>, <ulink
url="http://www.djangoproject.com/r/python-mysql/"/>
</entry>
</row>
<row>
<entry><token>django.db.backends.sqlite3</token></entry>
<entry>SQLite</entry>
<entry>
При использовании Python 2.5+ драйвер не нужен. В
противном случае <ulink
url="http://www.djangoproject.com/r/python-sqlite/"/>
</entry>
</row>
<row>
<entry><token>django.db.backends.oracle</token></entry>
<entry>Oracle</entry>
<entry>
<token>cx_Oracle</token>, <ulink
url="http://www.djangoproject.com/r/python-oracle/"/>
</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Следует отметить, что для работы с базой данных
потребуется скачать и установить соответствующий
драйвер. Каждый описанный драйвер доступен бесплатно,
просто проследуйте по ссылке, которая приведена в колонке
<quote>Драйвер</quote>. Если вы используете Linux,
вероятно ваша система управления пакетами может предложить
соответствующие пакеты. (Например, ищите пакеты с именами
<token>python-postgresql</token> или
<token>python-psycopg</token>.)
</para>
</listitem>
<listitem>
<para>
Параметр <varname>NAME</varname> указывает Django
имя вашей базы данных. Например:
<screen>
<![CDATA[
'NAME': 'mydb'
]]>
</screen>
</para>
<para>
Если вы использует SQLite, укажите полный путь к файлу
базы данных на файловой системе. Например:
<screen>
<![CDATA[
'NAME': '/home/django/mydata.db'
]]>
</screen>
</para>
<para>
Мы используем каталог <filename>/home/django</filename> в
этом примере, но вам следует выбирать каталог, который
более подходит для вашей задачи.
</para>
</listitem>
<listitem>
<para>
Параметр <varname>USER</varname> указывает Django
какое имя надо использовать при соединении с базой
данных. Если вы используете SQLite, оставьте этот параметр
пустым.
</para>
</listitem>
<listitem>
<para>
Параметр <varname>PASSWORD</varname> указывает
Django какой пароль надо использовать при соединении с
базой данных. Если вы используете SQLite, оставьте этот
параметр пустым.
</para>
</listitem>
<listitem>
<para>
Параметр <varname>HOST</varname> указывает Django
какое имя сервера надо использовать при соединении с базой
данных. Если база данных находится на том же компьютере
(т.е., <token>localhost</token>), оставьте параметр
пустым. Если вы используете SQLite, оставьте этот параметр
пустым.
</para>
<para>
MySQL является особым случаем. Если значение этого
параметра начинается с прямого слэша (<token>/</token>) и
вы используете MySQL, то соединение будет произведено
через UNIX сокет, например:
<screen>
DATABASE_HOST = '/var/run/mysql'
</screen>
</para>
</listitem>
<listitem>
<para>
(Прим. переводчика) Скопировано из прошлой версии книги,
так как не потеряло актуальность.
</para>
<para>
Параметр <varname>PORT</varname> указывает Django
какой порт надо использовать при соединении с базой
данных. Если вы используете SQLite, оставьте этот параметр
пустым. В противном случае, соответствующий драйвер базы
данных будет использовать стандартный (для конкретной базы
данных) порт. В большинстве случаев используется
стандартный порт, можете оставить этот параметр пустым.
</para>
</listitem>
</itemizedlist>
</para>
<para>
После заполнения этих параметров, проверьте свою
конфигурацию. Чтобы выполнить это, запустите <command>python
manage.py shell</command>, как делали это в прошлой главе, в
каталоге проекта <filename>mysite</filename>. (Как мы
рассказывали в прошлой главе команда <command>manage.py
shell</command> является способом запуска интерпретатора Python
с корректной конфигурацией Django проекта. Это необходимо в
нашем случае, так как Django должна знать какой файл
конфигурации следует использовать для получения учётных данных
для работы с базой данных.)
</para>
<para>
В интерпретаторе выполните нижеприведённые команды для проверки
ваших настроек для соединения с базой данных:
<screen>
<![CDATA[
>>> from django.db import connection
>>> cursor = connection.cursor()
]]>
</screen>
</para>
<para>
Если ничего не произойдёт, значит всё сделано правильно. В
противном случае, изучите сообщение об ошибке и выясните, что
произошло. Таблица <quote><xref linkend="&BASEID;.tbl2"
endterm="&BASEID;.tbl2.title"/></quote> содержит некоторые
стандартные ошибки.
</para>
<para>
<table id="&BASEID;.tbl2" frame="all" pgwide="1">
<title id="&BASEID;.tbl2.title">
Сообщения об ошибках в конфигурации доступа к базе данных
</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
<colspec colname="c1" colwidth="7cm"/>
<colspec colname="c2" colwidth="7cm"/>
<thead>
<row rowsep="1">
<entry>Сообщение об ошибке</entry>
<entry>Решение</entry>
</row>
</thead>
<tbody>
<row>
<entry>
Вы не определили значение параметра
<varname>ENGINE</varname>. (You haven't set
the ENGINE setting yet.)
</entry>
<entry>
Установите значение параметра
<varname>ENGINE</varname>. Не оставляйте его
пустым.
</entry>
</row>
<row>
<entry>
Не определена переменная среды
<varname>DJANGO_SETTINGS_MODULE</varname>. (Environment
variable DJANGO_SETTINGS_MODULE is undefined.)
</entry>
<entry>
Запустите команду <command>python manage.py
shell</command> вместо <command>python</command>.
</entry>
</row>
<row>
<entry>
Ошибка при загрузке модуля _____. Нет модуля с именем
_____. (Error loading _____ module: No module named
_____.)
</entry>
<entry>
Вы не установили соответствующий драйвер базы данных,
т.е. <token>psycopg</token> или
<token>MySQLdb</token>.
</entry>
</row>
<row>
<entry>
_____ не является доступным драйвером базы
данных. (_____ isn't an available database backend.
</entry>
<entry>
Установите параметр
<varname>ENGINE</varname>, указав
используемую базу данных, как было описано
ранее. Возможно вы опечатались?
</entry>
</row>
<row>
<entry>
База данных _____ не существует. (database _____ does
not exist.)
</entry>
<entry>
Измените параметр <varname>NAME</varname>, чтобы
он указывал на существующую базу данных, или выполните
соответствующую команду <command>CREATE DATABASE</command>
для создания базы данных.
</entry>
</row>
<row>
<entry>
Роль _____ не существует. (role _____ does not exist.)
</entry>
<entry>
Измените параметр <varname>USER</varname>,
чтобы он указывал на существующего пользователя или
создайте соответствующего пользователя в базе данных.
</entry>
</row>
<row>
<entry>
Не могу подключиться к серверу. (could not connect to
server.)
</entry>
<entry>
Удостоверьтесь, что параметры
<varname>HOST</varname> и
<varname>PORT</varname> установлены
правильно, а также, что сервер баз данных работает.
</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</section>
<section id="&BASEID;.firstapp">
<title id="&BASEID;.firstapp.title">
Ваше первое приложение
</title>
<para>
После того, как вы проверили работоспособность соединения с
базой данных, пришло время создать
<emphasis>Django-приложение</emphasis> — код, включающий в
себя модели и представления, который объединён в один пакет
Python и представляет собой цельное Django-приложение.
</para>
<para>
Удобно согласовать терминологию здесь, это поможет новичкам. В
главе <quote><xref linkend="djangobook.chap02.startproject"
endterm="djangobook.chap02.startproject.title"/></quote> мы
создали проект, но в чём же разница между проектом и
приложением? Разница в том, что первое является конфигурацией, а
второе — кодом:
<itemizedlist>
<listitem>
<para>
Проект — это экземпляр определённого набора кода
Django-приложений и конфигурация для этих приложений.
</para>
<para>
С технической точки зрения существует одно требование к
проекту — наличие файла конфигурации, который
определяет способ соединения с базой данных, список
установленных приложений, каталог с шаблонами и так далее.
</para>
</listitem>
<listitem>
<para>
Приложение — это переносимый набор некой
функциональности, обычно включает в себя модели и
представления, которые хранятся вместе в едином пакете
языка Python.
</para>
<para>
Например, Django поставляется с рядом приложений, таких
как система комментирования и автоматический интерфейс
администратора. Важной особенностью этих приложений
является то, что они переносимы и их можно использовать во
множестве проектов.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Существует очень мало жёстких правил для соответствия вашего
кода этой схеме. Если вы создаёте простой сайт, вы можете
использовать единственное приложение. Если вы создаёте сложный
сайт с несколькими независимыми частями, такими как
интернет-магазин и форум, возможно вы пожелаете разнести их в
отдельные приложения, что позволит использовать их раздельно в
других проектах.
</para>
<para>
В действительности нет нужды создавать приложения вообще, как
это видно из примера функций представления, которые мы создали
ранее. Для тех случаев мы просто создали файл с именем
<filename>views.py</filename>, который содержал код функций
представления и создали схему URL для этих функций. Никакое
<quote>приложение</quote> нам для этого не понадобилось.
</para>
<para>
Тем не менее, существует одно требование относящееся к
приложениям: если вы используете Django API для работы с базой
данных, то вы обязаны создать приложение. Модели должны
находиться внутри приложения. Следовательно, для того, чтобы
начать описывать наши модели нам потребуется создать новое
приложение.
</para>
<para>
Внутри каталога проекта <filename>mysite</filename> выполните
эту команду для создания приложения
<application>books</application>:
<screen>
<![CDATA[
python manage.py startapp books
]]>
</screen>
</para>
<para>
Эта команда ничего не выводит, она просто создаёт каталог
<filename>books</filename> в каталоге
<filename>mysite</filename>. Давайте глянем на содержимое этого
каталога:
<screen>
<![CDATA[
books/
__init__.py
models.py
views.py
]]>
</screen>
</para>
<para>
Эти файлы будут содержать модели и представления для приложения.
</para>
<para>
Посмотрите с помощью вашего текстового редактора файлы
<filename>models.py</filename> и
<filename>views.py</filename>. Оба файла сейчас пустые, исключая
импорт в <filename>models.py</filename>. Это каркас для вашего
приложения.
</para>
</section>
<section id="&BASEID;.defmodels">
<title id="&BASEID;.defmodels.title">
Определение моделей в Python
</title>
<para>
Как мы рассказывали в этой главе ранее, буква <quote>M</quote> в
<token>MTV</token> определяет слово <quote>Модель</quote>
(Model). Модель в Django — это описание данных, которые
хранятся в базе данных, выполненное в виде кода на языке
Python. Это форма ваших данных — эквивалент SQL операторов
<command>CREATE TABLE</command> — только описана она на
языке Python вместо SQL и включает в себя не только определение
столбцов в базе данных. Django использует модель для фонового
выполнения SQL и возвращает удобные структуры Python с данными,
представляющими записи в таблицах вашей базы данных. Django
также использует модели для представления высокоуровневых
концепций, которые SQL вряд ли сможет обработать.
</para>
<para>
Если вы уже работали с базами данных, вы могли подумать:
<quote>Зачем дублировать определение моделей данных в Python
<emphasis>и</emphasis> в SQL?</quote> Django действует таким
образом по нескольким причинам:
<itemizedlist>
<listitem>
<para>
Самодиагностика занимает ресурсы и несовершенна. Для того,
чтобы предоставить удобный API для доступа к данным,
Django должна <emphasis>как-то</emphasis> получить
информацию о содержимом базы данных и существует два
способа сделать это. Первый: можно явно описать данные в
Python. Второй: самодиагностика базы данных при работе
приложения для определения моделей данных.
</para>
<para>
Второй способ кажется более очевидным, так как метаданные
в ваших таблицах хранятся в одном месте, но он приводит к
нескольким проблемам. Первое, самодиагностика базы данных
во время работы приложения потребляет ресурсы. Если среде
разработки потребуется проверять структуру базы данных при
выполнении каждого запроса, или хотя бы при каждом запуске
веб-сервера, вы получите значительную нагрузку на ресурсы
сервера. (В то время как некоторые считают такую нагрузку
приемлемой, разработчики Django нацелены на максимально
возможную скорость работы среды. И этот подход успешно
решает задачу обгона конкурентов в тестах.) Во-вторых,
некоторые базы данных, особенно старые версии MySQL, не
сохраняют достаточно метаинформации для точной и полной
самодиагностики.
</para>
</listitem>
<listitem>
<para>
Разрабатывать с помощью Python прикольно и хранение всего
в виде его кода сокращает число <quote>переключений
контекста</quote>, которые приходится делать вашему
мозгу. Если придерживаться единой среды
разработки/менталитета, это повысит продуктивность
работы. Необходимость писать SQL, затем код Python, а
потом опять SQL, отрицательно сказывается на
производительности разработчика.
</para>
</listitem>
<listitem>
<para>
Когда модели данных хранятся в виде кода, а не в базе
данных, это упрощает управление версиями этих моделей. Это
поможет вам хранить историю всех изменений моделей.
</para>
</listitem>
<listitem>
<para>
SQL позволяет лишь определённый уровень хранения
метаинформации о формате данных. Большинство систем
управления базами данных не предоставляют
специализированных типов данных для представления адресов
электронной почты или URL. Модели Django
предоставляют. Преимущество высокоуровневых типов данных в
улучшении продуктивности и в большем повторном
использовании кода.
</para>
</listitem>
<listitem>
<para>
SQL несовместим между разными платформами баз данных. При
распространении веб-приложения, более практично передавать
модуль на языке Python, который описывает формат ваших
данных, вместо отдельных наборов операторов
<command>CREATE TABLE</command> для MySQL, PostgreSQL и
SQLite.
</para>