bo858585 / abstractbooking Goto Github PK

В нем есть EXPLAIN.

Приоритет: высокий

Приоритет: высокий

1. Профилирование sql-запросов:

http://www.varlena.com/GeneralBits/Tidbits/perf.html#intro
http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
http://linuxfinances.info/info/quickstart.html

Настроить postgreSQL.conf - ввести рекомендуемые в man параметры. Параметры зависят от параметров аппаратуры в том числе.

Cоздается таблица заказов с большим числом записей N = 1000000:

1. CreateBookingView - INSERT N rows
   (Вставить через dbshell 1000000 строк для 2,3,4)
2. UpdateBookingView - UPDATE N rows
3. BookingListView - SELECT N rows
4. DeleteBookingView - DELETE N rows

Взять запросы из этих django views, получить их SQL, распечатав его в консоль в django-коде. Для view: str(get_queryset().query).
http://simeonfranklin.com/blog/2011/feb/14/hidden-django-queryset-features-i/

Сделать в psql EXPLAIN этих запросов.
Откорректировать параметры в postgresql.conf, отвечающие за эти операции (размер дискового кеша при выборке данных, частота сброса данных на диск при их вставке и обновлении, удаление мусора при их удалении и обновлении и т.д.).

Создать в Postgresql индексы в таблицах, использующихся в этом view.
Выяснить через EXPLAIN, как менятся время работы запросов при добавлении индекса.

Параметры postgreSQL.conf:

shared_buffers = 450MB # (1/4 memory) Общий кэш PostgreSQL
effective_cache_size = 1.5GB # 50-75% of full memory, вся ожидаемая память под кэш, используется планировщиком для определения вероятнсти того, будет ли запрос работать с диском или данные уже доступны в памяти
work_mem = 50MB # память для сортировки данных, используемая одним запросом.

checkpoint_segments - данные из буферов сбрасываются на диск при проходе контрольной точки при заполнении нескольких (параметр checkpoint_segments, по умолчанию 3) сегментов журнала транзакций.
checkpoint_timeout - либо через определённый интервал времени (параметр checkpoint_timeout, измеряется в секундах, по умолчанию 300).

listen_addresses = '*' # localhost

2 . Возможно стоит запустить через nginx написанные unit performance тесты и измерить время работы.

На их основе сделать индексы.
https://docs.djangoproject.com/en/1.7/topics/db/optimization/

Если вход на страницу редактирования заказа был с /own_booking_list/, то при редактировании возврат должен происходить на ту же страницу. Для /booking_list/ - то же самое.

При добавлении комментария пользователь должен остаться на соответствующей странице /booking_detail/id/

Утилитой.

После написания тестов в мастер-ветке их быть не должно.

Необходимо добавить кастомные права.

Использовать двух пользователей - каждый из них добавляет комментарии.
Проверка наличия комментариев в базе и на странице.
Приоритет: высокий

И nginx.

Приоритет: высокий.

Ветка md5_authentification
Приоритет: высокий
https://stackoverflow.com/questions/26649634/is-postgresql-peer-authentication-safe-for-production
http://www.postgresql.org/docs/9.4/static/auth-methods.html

(Сэмулировать локально)

del

Приоритет: высокий

Прерыванием транзакции через exit().

При включенном AJAX не происходит сокрытия заказов (нужно перезагружать
страницу) - AJAX ответ при взятии/завершении заказа не обрабатывается на стороне клиента.

С двумя ссылками - на список задач и на форму создания задачи.

1. Если статус PENDING, заказ удаляется.
2. Если статус RUNNING, заказ удалить нельзя.
3. Если статус COMPLETED, заказ удаляется.

В ветке nginx_https.
http://nginx.org/ru/docs/http/configuring_https_servers.html
Сгенерировать самоподписанный сертификат.
http://dracoblue.net/dev/https-nginx-with-self-signed-ssl-certificate/
Приоритет: высокий

https://stackoverflow.com/questions/4551175/how-to-cancel-abort-jquery-ajax-request

Приоритет: высокий

Проверить все модели.

Тесты для views и models.

Когда исполнитель берет заказ, у заказчика на заказе должны появиться две кнопки: "Подтвердить"/"Отклонить" - означающие, подтверждение или отклонение заказчиком попытки исполнителя взять заказ. У исполнителя после нажатия на кнопку взятия заказа эта кнопка скрывается. Статус заказа - должен измениться на "waiting_for_approving". После подтверждения должно работать как и сейчас - статус заказа running. После отклонения статус заказа становится pending.

Статус: высокий

Для формы ввода текста заказа.

В домашнюю страницу.

Поместить в css.

Для разрешения спорных ситуаций в процессе выполнения заказа.

Приоритет: высокий

для обратной связи (например, в спорных ситуациях)

Приоритет: высокий

В форме создания заказа сделать сохранение значений полей при ошибке и подсветку.
Поправить стиль вывода ошибок.
Приоритет: очень низкий

messages не показываются на стороне клиента при отключенном AJAX.

http://www.dalibo.org/_media/understanding_explain.pdf

Доступны только ему.

Приоритет: очень низкий
После того, как пользователь отправил запрос на сервер и взял заказ, на экран выводится сообщение о его взятии. Необходимо задизейблить через JQuery кнопку взятия заказа в той строке таблицы, в которой производился заказ. То же самое для кнопки завершения заказа.

venv, nginx, app server, app), сделать инструкцию

Usability

Приоритет: низкий
Регистрация должна содержать выбор типа пользователя customer/performer.
При регистрации должны создаваться расширенный профиль пользователя UserProfile со счетом и производиться добавление его к выбранной группе customers/performers.

Приоритет: низкий
Регистрация должна содержать выбор типа пользователя customer/performer.
При регистрации должны создаваться расширенный профиль пользователя UserProfile со счетом и производиться добавление его к выбранной группе customers/performers.