Архив метки: Django

Сравнение Django и SQLAlchemy

По мере того, как со временем развивается и совершенствуется все больше и больше технологий, количество пользователей, получающих доступ в Интернет, растет еще больше, и в результате объем данных, с которыми приходится иметь дело предприятиям и организациям, растет в геометрической прогрессии. Чтобы компания была успешной, ей нужны инструменты и инфраструктура, которые могут легко работать с этими большими наборами данных. Именно здесь появляется база данных, которая в основном предназначена для хранения и сбора данных. Более того, его организованная форма позволяет пользователям легко управлять набором данных и получать к нему доступ. Сами базы данных требуют системы управления, которая позволяет им хранить и предоставлять доступ к данным. В основном язык SQL используется для выполнения операций в базе данных, однако по мере роста и усложнения вашего приложения,

Альтернативой этому была разработана структура ORM (объектно-реляционное сопоставление), которая фактически создает мост между базой данных и языком программирования, который вы предпочитаете использовать при создании своего приложения. В этой статье мы рассмотрим и сравним плюсы и минусы двух наиболее популярных и широко используемых ORM, Django и SQLAlchemy.

 

Django против SQLAlchemy

Оба ORM — Django и SQLAlchemy — два самых популярных инструмента реляционного сопоставления на основе Python, и каждый из них имеет свои собственные уникальные преимущества. Давайте теперь перекрестно исследуем и рассмотрим оба их различия бок о бок.

 

1) Реализация уровня доступа к данным

Django использует так называемую реализацию активной записи, в которой один экземпляр объекта сопоставляется с каждой строкой базы данных, и данные легко доступны из базы данных. Здесь нет необходимости заранее настраивать схему базы данных, и они могут легко использоваться пользователями, поскольку основная идея в Django заключается в том, что он может понять структуру напрямую, просто взглянув на схему базы данных. В дополнение к этому, поскольку это прямое сопоставление между базой данных и объектом, любое изменение объекта также будет обновлено в базе данных.

SQLAlchemey использует реализацию Data Mapper, которая действует как средний уровень между вашим приложением и базой данных и передает данные между ними, сохраняя при этом их соединение независимо друг от друга. Это обеспечивает большую гибкость между двумя уровнями, а также более эффективное использование базы данных.

 

2) Лучше со сложными запросами

И Django, и SQLAlchemy — два отличных ORM, которые предоставляют одни из лучших функций, которые вы можете найти в инструментах реляционного сопоставления. С точки зрения обработки сложных запросов SQLAlchemy имеет преимущество, поскольку он намного лучше взаимодействует с базой данных и, как результат, его можно использовать для написания сложных запросов без необходимости возвращаться к необработанному SQL. Чтобы понять эту концепцию, давайте взглянем на следующие запросы, написанные как на Django, так и на SQLAlchemy.

Django:

Football.objects.filter(team__name="Manchester United")

SQLAlchemy:

SQLAlchemy: session.query(Football).join(Football, Team).filter(Team.name=="Kamma Sing")

 

Как видно из синтаксиса двух ORM, Django выглядит более абстрактным в своем запросе и показывает только установленное соединение между различными таблицами базы данных, в то время как SQLAlchemy идет гораздо глубже. Это различие между ними показывает, что Django гораздо более ленив и эффективнее справляется со сложными запросами.

 

3) Поддержка сообществ и баз данных

И Django, и SQLAlchemy являются чрезвычайно популярными фреймворками для реляционного сопоставления, и они поддерживаются некоторыми чрезвычайно удивительными сообществами. Последний, однако, превосходит это, поскольку имеет гораздо большее сообщество вместе с совершенно потрясающей документацией, которая свидетельствует о том, что члены сообщества вкладывают в это свое время. Даже если вы столкнетесь с какой-либо проблемой, вы можете легко опубликовать сообщение на StackOverflow или других форумах, и там найдется большое количество людей, желающих вам помочь.

Наряду с этим и Django, и SQLAlchemy поддерживают большой набор баз данных, таких как MySQL, PostgreSQL, Oracle и SQLite. Для пользователей, которые уже используют Microsoft SQL или планируют это сделать, SQLAlchemy снова является ответом, поскольку MSSQL обеспечивает его полную поддержку.

В целом, у обоих есть отличные сообщества и поддержка множества баз данных, что является хорошим признаком огромного качества, которым обладает каждая из них.

 

4) Приложения

Django был разработан в основном для веб-приложений, и именно там он работает лучше всего, поскольку имеет множество встроенных инструментов, таких как интеграция форм, предварительная проверка и т. Д .; все они чрезвычайно полезны для веб-приложений. В дополнение к этому, если вам просто требуются базовые запросы, тогда Django будет работать довольно хорошо, поскольку его также намного легче изучить.

Однако, если ваши веб-приложения или фреймворки требуют немного более сложных запросов, то SQLAlchemy — это то, что вам нужно. В дополнение к этому, поскольку он напрямую взаимодействует с базой данных, вы можете просто запускать запросы к базе данных, фактически не используя ORM. Кроме того, SQLAlchemy намного мощнее, чем Django, хотя и требует немного большего обучения.

 

Вывод:

И Django, и SQLAlchemy являются чрезвычайно популярными инструментами объектно-реляционного сопоставления, имеют большие сообщества для их поддержки и используются в широком спектре приложений по всему миру. Какой из них вам больше подходит? Это в основном зависит от ваших требований и от того, где именно вы хотите их использовать. В общем, оба являются отличным выбором для использования в качестве вашей системы ORM.



2021-03-24T13:28:16
Базы данных

Великолепная четверка книг по Django

Интернет вошел в жизнь буквально каждого. Мы постоянно пользуемся самыми разными сайтами и приложениями для самых разных нужд, — пишет сайт pythonist.ru.

Если вспомнить о том, что Python — один из самых популярных языков программирования, нет ничего удивительного в том, что его широко используют и для создания сайтов. В частности, для этой цели был создан Django — один из самых популярных веб-фреймворков Python. Читать

Запуск проектов Django в VestaCP

В этой статье рассмотрим запуск Django проектов в панели управления VestaCP, в различных конфигурациях. Подразумевается что у вас уже установлена и настроена панель VestaCP, как это сделать можно прочитать здесь. А так же установлен и запущен фреймворк Djang, как это сделать смотрите здесь.

VestaCP Nginx+Apache

если у вас VestaCP установлена в конфигурации nginx-apache, то здесь все просто, достаточно установить mod_wsgi

В Ubuntu

apt-get install libapache2-mod-wsgi

a2enmod wsgi

В CentOS, RedHat

yum install mod_wsgi

Затем добавить в VestaCP новый шаблон.

Для Ubuntu

cd /usr/local/vesta/data/templates/web

wget http://c.vestacp.com/0.9.8/ubuntu/wsgi/apache2.tar.gz

tar -xzvf apache2.tar.gz

rm -f apache2.tar.gz

Для CentOS, RedHat

cd /usr/local/vesta/data/templates/web

wget http://c.vestacp.com/0.9.8/rhel/wsgi/httpd.tar.gz

tar -xzvf httpd.tar.gz

rm -f httpd.tar.gz

Переходим в WEB интерфейс VestaCP, и выбираем WEB Template wsgi. После чего все должно работать.

VestaCP Nginx+php-fpm

Дальнейшие настройки будут проводиться для домена example.com, а пользователь в панели VestaCP admin, поэтому при дальнейших действиях используйте свои логин и домен

Для начала устанавливаем модуль uwsgi и uwsgi-plugin-python2

yum install uwsgi uwsgi-plugin-python2  –y

Проверяем работу модуля uwsgi, для этого запустим его с ключами

uwsgi --chdir /home/admin/web/example.com/public_html/mysite/ --http-socket :8000 --plugin python --wsgi-file /home/admin/web/example.com/publictml/mysite/mysite/wsgi.py

chdir – полный путь к проекту Django

http-socket – порт по которому модуль слушает http запросы, т.к 80  порт у нас занят, то для теста используем 8000

wsgi-file –путь к файлу с настройками окружения, должен создаться автоматически при создании проекта в Django.

После запуска открываем в браузере ссылку

http://<ip адрес сервера>:8000

Мы должны увидеть страницу приветствия.

Или если у вас уже рабочий сайт, то он должен открыться

После установки модуля в каталоге /etc появится основной файл настроек /etc/uwsgi.ini

Посмотрим его

cat  /etc/uwsgi.ini

Сразу у меня он не заработал, поэтому пришлось отредактировать. В итоге рабочий ini-файл получился такой.

[uwsgi]

uid = uwsgi

gid = uwsgi

pidfile = /run/uwsgi/uwsgi.pid

emperor = /etc/uwsgi.d

chmod-socket = 660

eror-tyrant = false

cap = setgid,setuid

Основной параметр в этом файле это emperor = /etc/uwsgi.d, он указывает директорию с конфигурационными файлами для различных сайтов . Т.е модуль запускается в режиме emperor и подгружает конфигурации из каталога /etc/uwsgi.d. Необходимо будет для каждого сайта создать свой ini-файл и поместить его в этот каталог.

Создаем директорию /run/uwsgi/

mkdir /run/uwsgi/

Меняем владельца на uwsgi

chown uwsgi:uwsgi /run/uwsgi/

chown uwsgi:uwsgi /etc/uwsgi.d/

Переходим в директорию /etc/uwsgi.d

cd /etc/uwsgi.d

и создаем файл example.com.ini следующего содержания

[uwsgi]

#Пользователь от которого запускается процесс uwsgi

uid=admin

gid=admin

#Путь к проекту django

chdir  = /home/admin/web/example.com/public_html/mysite/

plugin = python

# Django wsgi файл

wsgi-file = /home/admin/web/example.com/public_html/mysite/mysite/wsgi.py

master  = true

# максимальное количество процессов

processes = 10

# полный путь к файлу сокета

socket = /home/admin/web/example.com/public_html/example.com.sock

chmod-socket = 666

# очищать окружение от служебных файлов uwsgi по завершению

vacuum = true

Для проверки запускаем модуль уже с использованием ini файла

uwsgi --http-socket :8000 --ini /etc/uwsgi.ini

Если вы получите ошибку Permission denied. Попробуйте изменить пользователя в файле /etc/uwsgi.ini

uid=uwsgi

gid=uwsgi

Замените на

uid=admin

gid=admin

А также измените права на папки

chown admin:admin /run/uwsgi/

chown admin:admin /etc/uwsgi.d/

На одном из серверов у меня заработало только после таких манипуляций. Пробуем запустить

uwsgi --http-socket :8000 --ini /etc/uwsgi.ini

Если все нормально и модуль запускается без ошибок,  вывод должен быть что то типа такого

идем дальше. Добавляем модуль в автозагрузку, для этого, добавляем в файл /etc/uswgi.ini параметр daemonize=/var/log/uwsgi/yourproject.log. В итоге файл должен выглядеть так

прописываем в файл /etc/rc.local в конце строку запуска

/usr/sbin/uwsgi --ini /etc/uwsgi.ini

Настройка Nginx

Добавляем в панель VestaCP новый шаблон django_uwsgi. Для этого переходим в директорию /usr/local/vesta/data/templates/web/nginx/php-fpm/

cd /usr/local/vesta/data/templates/web/nginx/php-fpm/

Здесь создаем два файла django_uwsgi.tpl и django_uwsgi.stpl

django_uwsgi.tpl

upstream django {

     server unix://%home%/%user%/web/%domain%/public_html/%domain%.sock;

    }

server {

    listen      %ip%:%web_port%;

    server_name %domain_idn% %alias_idn%;

    root        %docroot%;

    index       index.php index.html index.htm;

    access_log  /var/log/nginx/domains/%domain%.log combined;

    access_log  /var/log/nginx/domains/%domain%.bytes bytes;

    error_log   /var/log/nginx/domains/%domain%.error.log error;

    location / {                 

        uwsgi_pass  django;      

        include /etc/nginx/uwsgi_params;

    }   

    location /static {

        alias  %home%/%user%/web/%domain%/public_html/static;

          } 

    location /media {

        alias  %home%/%user%/web/%domain%/public_html/media;

          }                        

    error_page  403 /error/404.html;

    error_page  404 /error/404.html;

    error_page  500 502 503 504 /error/50x.html;

    location /error/ {

        alias   %home%/%user%/web/%domain%/document_errors/;

    }

    location ~* "/.(htaccess|htpasswd)$" {

        deny    all;

        return  404;

    }

    location /vstats/ {

        alias   %home%/%user%/web/%domain%/stats/;

        include %home%/%user%/conf/web/%domain%.auth*;

    }

    include     /etc/nginx/conf.d/phpmyadmin.inc*;

    include     /etc/nginx/conf.d/phppgadmin.inc*;

    include     /etc/nginx/conf.d/webmail.inc*;

    include     %home%/%user%/conf/web/nginx.%domain%.conf*;

}

django_uwsgi.stpl

server {

    listen      %ip%:%web_ssl_port%;

    server_name %domain_idn% %alias_idn%;

    root        %sdocroot%;

    index       index.php index.html index.htm;

    access_log  /var/log/nginx/domains/%domain%.log combined;

    access_log  /var/log/nginx/domains/%domain%.bytes bytes;

    error_log   /var/log/nginx/domains/%domain%.error.log error;

    ssl         on;

    ssl_certificate      %ssl_pem%;

    ssl_certificate_key  %ssl_key%;

    location / {                 

        uwsgi_pass  django;      

        include /etc/nginx/uwsgi_params;

    }

     location /static {

         alias  %home%/%user%/web/%domain%/public_html/static;

                }

     location /media {

        alias  %home%/%user%/web/%domain%/public_html/media;

                }                          

    error_page  403 /error/404.html;

    error_page  404 /error/404.html;

    error_page  500 502 503 504 /error/50x.html;

    location /error/ {

        alias   %home%/%user%/web/%domain%/document_errors/;

    }

    location ~* "/.(htaccess|htpasswd)$" {

        deny    all;

        return  404;

    }

    location /vstats/ {

        alias   %home%/%user%/web/%domain%/stats/;

        include %home%/%user%/conf/web/%domain%.auth*;

    }

    include     /etc/nginx/conf.d/phpmyadmin.inc*;

    include     /etc/nginx/conf.d/phppgadmin.inc*;

    include     /etc/nginx/conf.d/webmail.inc*;

    include     %home%/%user%/conf/web/snginx.%domain%.conf*;

}

Обратите внимание, на расположение каталогов static и media проектов django, в моих шаблонах они находятся в корне каталога public_html.

Файл /etc/nginx/uwsgi_params должен был создаться при установки uwsgi, если нет, создайте его.

uwsgi_params

uwsgi_param  QUERY_STRING       $query_string;

uwsgi_param  REQUEST_METHOD     $request_method;

uwsgi_param  CONTENT_TYPE       $content_type;

uwsgi_param  CONTENT_LENGTH     $content_length;



uwsgi_param  REQUEST_URI        $request_uri;

uwsgi_param  PATH_INFO          $document_uri;

uwsgi_param  DOCUMENT_ROOT      $document_root;

uwsgi_param  SERVER_PROTOCOL    $server_protocol;

uwsgi_param  REQUEST_SCHEME     $scheme;

uwsgi_param  HTTPS              $https if_not_empty;



uwsgi_param  REMOTE_ADDR        $remote_addr;

uwsgi_param  REMOTE_PORT        $remote_port;

uwsgi_param  SERVER_PORT        $server_port;

uwsgi_param  SERVER_NAME        $server_name;

Теперь через WEB интерфейс выбираем наш шаблон djago_wsgi

Сохраняем и переходим на сайт example.com, естественно вместо example.com должен быть ваш рабочий домен. Если видим страницу

Или страницу вашего сайта, то значит у нас все работает.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.



2018-11-22T20:31:09
Django

Установка Django на CentOS 7, запуск и тестирование

В данной статье рассмотрим установку и запуск первого проекта в Django на ОС Centos7

Установка Django

Первым делом устанавливаем pip

yum install python-pip –y

Далее устанавливаем само Django. Но просто дать команду

pip install django

Не получится, вы получите ошибку Unsupported Python version

Дело в том,  что в Centos 7 при чистой установке установлен python 2.7. Тут два выхода, можно установить 3-й python, или установить более старую версию Django. Пойдем по пути наименьшего сопротивления и установим версию поддерживаемую python 2.7.  Переходим на сайт https://docs.djangoproject.com/en/2.1/faq/install/. И видим что для нашей версии питон подходит Django 1.11. Вот ее и установим

pip install Django==1.11

Теперь установка должна пройти без ошибок

Запуск проекта

Создадим наш первый проект. Переходим в директорию где у нас будут храниться сайты, например /var/www/html/

cd  /var/www/html/

Даем команду на создание проекта, например проект будет называться mysite, тогда команда будет

django-admin startproject mysite

посмотрим что создала эта команд команда

ls –R

mysite – корневой каталог нашего проекта

manage.py – файл для выполнения различных интерактивных команд для Django. Например запуск внутреннего web сервера. Полный список команд можно посмотреть набрав

python manage.py

В каталоге /mysite/mysite/ содержатся конфигурационные файлы.

Settings.py –файл с основными настройками сайта, такими как задание языка, временной зоны, параметров подключения к базе и т.д.

urls.py – настройки URL

wsgi.py –файл для работы с модулем wsgi, нужен для работы джанго в web серверах apache или nginx.

Тестирование работы Django

Проверим работу нашего приложения, для этого выполните команду

python manage.py runserver 0.0.0.0:8000

После чего наберите в строке браузера

http://<ip адрес вашего сервера>:8000

При первом запуске у вас скорее всего появится ошибка You may need to add u’ip сервера’ to ALLOWED_HOSTS

Поэтому останавливаем сервер ctr^Z. Открываем на редактирование файл settings.py и ищем параметр

ALLOWED_HOSTS = []

Вписываем в квадратные скобки ip адрес сервера, например

ALLOWED_HOSTS = [’10.10.10.10’]

Должно получится так

Снова запускаем сервер

python manage.py runserver 0.0.0.0:8000

И пытаемся подключиться на адрес http://10.10.10.10:8000/ . В итоге вы должны увидеть следующую страницу

Она говорит нам что Django успешно запущено и настроено.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

 



2018-11-22T12:54:07
Django

Сброс пароля на админку в django

Что делать если вы забали пароль от админки к django? Есть как минимум 2 решения проблемы.

Первое решение просто поменять пароль на root или другого суперпользователя, которого вы создали при создании базы данных. Для этого входим в manage.py shell

python manager.py shell

и набираем

>>>from django.contrib.auth.models import User

>>>user = User.objects.get( username='root')

>>>user.set_password(«password»)

>>>user.save()

Второй способ еще проще, он также пригодится если вы вместе с паролем забыли и логин от админки, в этом случае можно создать нового суперпользователя, для этого в терминале вводим

python manage.py createsuperuser

 И вводим новые данные.



2018-09-29T23:09:18
Django

Django. Отображение фотографий на HTML странице (часть 11)

Добавим теперь фотографии домов, для этого расширим модель. В файле models.py напишем:

photo = models.ImageField(«фотография», upload_to=»houses/photos», default=»», blank=True)

Мы создали поле house_photo, в котором будет храниться ссылка на изображение дома.

default =»» — значение по умолчанию, это пустая строка.
blank=True – говорит, что можно добавлять дом без фотографии.
upload_to=»houses/photos» — путь где будут храниться фотографии

Нажмем Ctrl+Alt+R – создадим миграцию

makemigrations houses
migrate houses

Возможно вы получите следующие ошибки

ERRORS:
houses.House.house_photo: (fields.E210) Cannot use ImageField because Pillow is not installed.
HINT: Get Pillow at https://pypi.python.org/pypi/Pillow or run command:
«pip install Pillow».

Для выполнения следующей миграции без ошибок, нам нужно установить библиотеку Pillow.
Pillow — это библиотека для работы с изображениями.

Выполним:

pip install Pillow

И снова мы можем увидеть следующие ошибки:

pip install pillow failed with error code 1
error for pip install Pillow on Ubuntu virtualenv
failed building wheel for Pillow

Для их исправления нужно выполнить следующие команды

sudo apt-get install python-dev
sudo apt-get install python3-dev
sudo apt-get install libjpeg8-dev zlib1g-dev

Теперь снова выполним команду и в этот раз должно все получиться:

pip install Pillow

Collecting Pillow
Using cached Pillow-3.2.0.zip
Building wheels for collected packages: Pillow
Running setup.py bdist_wheel for Pillow … done
Stored in directory: /home/vlad/.cache/pip/wheels/88/2d/ce/3ff4ae4e2b8600d1bde1cbde5dfcc6d8770222c38348fe9139
Successfully built Pillow
Installing collected packages: Pillow
Successfully installed Pillow-3.2.0

Снова выполним миграцию:

python manage.py makemigrations houses
python manage.py migrate houses

Теперь перейдем в settings.py и включим поддержку медиафайлов. Тоесть файлы, которые будем добавлять мы или наши клиенты через сайт.

Добавим переменную MEDIA_ROOT, которой присвоим «media»

os.path.join(BASE_DIR, «media»)

, то есть мы будем хранить файлы в папке «media», которая будет находится в папке проекта BASE_DIR

Также добавим переменную MEDIA_URL, которой присвоим строку «/media/»

MEDIA_URL — это адрес по которому пользователь сможет получить доступ к нашим медиа файлам.

Теперь перейдем в файл urls.py и импортируем в него функцию static

from django.conf.urls.static import static

А также импортируем настройки проекта:

from django.conf import settings

После, к urlpatterns прибавим функцию static()
Первым аргументом укажем settings.MEDIA_URL, а вторым именованный document_root=settings.MEDIA_ROOT

urlpatterns = [] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Переходим в админку, выбираем дом бюджет, теперь мы видим, что появилось новое поле Фотография, которое в отличии от других полей не выделено жирным, то есть оно не обязательно для заполнения. Добавим фото и нажмем сохранить. Фотография загрузится на сервер в папку houses/photos

Теперь в папке проекта должна появится папка media, внутри которой houses и photos, в соответствии со структурой upload_to

Выведем теперь фотографию на сайт. Откроем шаблон houses_list.html и напишем:

if, затем нажмем TAB, чтобы быстро создать инструкцию

{% if house.house_photo %}

{% endif %}

А в теле инструкции напишем:

img, затем нажмем TAB, чтобы быстро создать конструкцию

В скобках {{ }} добавим house.house_photo.url и house.house_name

Разберем код:

Мы добавили условие, если у дома есть фотография house.house_photo, то подставить в атрибут src=»» ссылку на неё {{ house.house_photo.url }}, а в атрибут alt=»» имя дома {{ house.house_name }}

Откроем сайт и посмотрим, фотография Бюджетного дома — теперь выводится.

Отлично!

Автор: Vladimir Semenovich