Да блин, вечер уже поздний, а я весь день бд туда загонял

да я без притензий =)

У меня теперь список фильтрации больше списка авто на странице :D

У меня теперь список фильтрации больше списка авто на странице :D

и страница долго грузится

Ну да, чёт жёстко

Ну надо как-то удобный фильтр сделать

Поиском не всё выводится почему-то

А есть более разумные варианты?

мне кажется в поиск надо выводить

А есть более разумные варианты?

Батарейки типа select2..

Поставил django-admin-list-filter-dropdown

Вроде норм штука, и грузится быстро

Вот это название длинное :)

надо было грапелли поставить у них вроде по дефолту фильтры в селектах

Обязательно почитаю что за зверь такой, пока вкладочку оставил

Щас этого хватит что бы продолжать работать

Там список ещё надо будет ужать до 800 штук где-то в следующей итерации синхронизации

А то я чёт всю базу перегнал

Щас просто надо модель бд настроить нормально

Всё равно не удобно выпадающей менюшкой, даже при 800 клиентах не удобно будет

Надо какой-то автозавершающийся поиск, но это наверное уже во фронтенд, сомневаюсь что такие плюшки есть в виде готовых пакетов

"You can look into django-grappelli, which is an app that enhances the admin interface. The documentation describes an autocomplete for ForeignKey or ManyToMany relationships, using raw_id_fields."

Хм

и select2 вроде тоже умеет

вопрос! 1. Есть домен, например example.com На нём организован сервер на джанго (контейнер в докере) а в нем авторизация юзеров. 2. Есть поддомен, например sub.example.com На нём так же отдельный джанго сервер (контейнер) крутится. Задача: сделать авторизацию общей! То есть если я залогинился на домене и зашел на поддомен чтобы авторизация не слетала и использовалась с основного сервера, с теми же правами. Как такое сделать лучше всего? Может есть готовые батарейки?

может через общие таблицы в базе или через id сайтов както решается? Я еще не сталкивался с таким

single sign on гугли)

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

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

ага, уже парочку открыл, смотрю

вопрос! 1. Есть домен, например example.com На нём организован сервер на джанго (контейнер в докере) а в нем авторизация юзеров. 2. Есть поддомен, например sub.example.com На нём так же отдельный джанго сервер (контейнер) крутится. Задача: сделать авторизацию общей! То есть если я залогинился на домене и зашел на поддомен чтобы авторизация не слетала и использовалась с основного сервера, с теми же правами. Как такое сделать лучше всего? Может есть готовые батарейки?

У тебя должен быть отдельный контейнер с базой к которой ты будешь подрубаться с двух сторон

project /project /landing /static +/assets/ +style.css /templates

project /project /landing /static +/assets/ +style.css /templates

почему статические файлы не включаются из папки assets, а style.css отрабатывает для страницы?

почему статические файлы не включаются из папки assets, а style.css отрабатывает для страницы?

collectstatic делался?

да, может из-за того что в шаблоне путь указан не так как нужно в django

<link rel="stylesheet" href="assets/bootstrap/css/bootstrap.min.css">

а в том котором стили отрабатывают написано:<link rel="stylesheet" href="{% static 'style.css' %}">

Да, вроде, именно из-за этого

а в том котором стили отрабатывают написано:<link rel="stylesheet" href="{% static 'style.css' %}">

вот так правильно

Ребят, есть вопрос: Можно ли как-то сделать prefetch\select_related при отработке to_representation у сериализатора? Кейс: POST запрос на create, создаю объект, к которому привязываю ещё пару побочных, и сразу хочу его вернуть. { items: [ { sub_item: { arg: value, } } , ... ] } Из-за вложенности, джанга делает много запрсов на каждый такой итем. В обычной ситуации, я вещаю на queryset prefetch\select в зависимости от связей, но как быть тут? Ведь у нас нет queryset-а, есть только один объект в сериализаторе верхнем (3 уровня, всё через NestedSerializers(many=True)) Структура сериализаторов (схематично): { class OneSerializer(): class TwoSerializer(): class ThreeSerializer(): args... }

Подсказали решение: def perform_create(self, serializer): serializer.save() item_with_all = Item.objects.filter(pk=serializer.instance.pk).prefetch_related(...) serializer.instance = item_with_all.first()

Работает. 13 запросов сократились до 3

13 - непостоянное число. 4n + 1

А как вообще правильно реализуется поиск с автозавершением?

Если у нас 5к наименований а аякс будет постоянно базу дёргать долго же будет работать, не?

Если у нас 5к наименований а аякс будет постоянно базу дёргать долго же будет работать, не?

во первых хорошо бы проиндексировать поля по которым будет поиск во вторых начинать отпправлять запрос с 3-5 символа, тем самым ограничивая львинную долю и увеличивая шанс получения нужного результата затем у тебя будет еще 3-4 запроса чтобы получить нужную информацияю что не много и при условии выполнения пункта первого будет достаточно быстро

В идеале я так понял ещё надо всё это в ОЗУ держать

кстати 5к не так много для базы

В идеале я так понял ещё надо всё это в ОЗУ держать

пока не торопись с этим

У меня база пока sqlite файловая, работает достаточно медленно

Так для теории спрашиваю, сегодня на sqlite ещё всё переносить

ой, чё я несу

в общем на настоящий sql

перенос в 3 команды делается

какието базы умеют держать что то в оперативной памяти надо почитать

Добрый день! Подскажите пожалуйста советом, как поступить? Я создаю модель в Django следующего вида: https://pastebin.com/7kuNqd5R В ней есть поле дата, и поле для файла. В файле будет находиться некий плейлист у которого в имени содержится дата ( например 01-01-2018.txt). При добавлении его в БД я хочу: 1) проверять, соответствует ли формату имя файла. 2) Брать дату из имени файла и писать в поле pl_date 3) При добавлении сразу парсить содержание плейлиста и записывать данные в другую таблицу БД. по п.1,2 я нагуглил определить в модели property set_file, get_file. по п.3 пока что идей нет.

Добрый день! Подскажите пожалуйста советом, как поступить? Я создаю модель в Django следующего вида: https://pastebin.com/7kuNqd5R В ней есть поле дата, и поле для файла. В файле будет находиться некий плейлист у которого в имени содержится дата ( например 01-01-2018.txt). При добавлении его в БД я хочу: 1) проверять, соответствует ли формату имя файла. 2) Брать дату из имени файла и писать в поле pl_date 3) При добавлении сразу парсить содержание плейлиста и записывать данные в другую таблицу БД. по п.1,2 я нагуглил определить в модели property set_file, get_file. по п.3 пока что идей нет.

pl_src_id лишнее.. Можно выбрать из save, pre_save, post_save

с точки зрения архитектуры насколько правильно переопределять save, pre_save

может это лучше сделать не в модели

post_save и pre_save это сигналы и выносятся отдельно

переопределять save нормально но конкретно в этом случае лучше вынести в сигнал либо вообще в селери

переопределять save нормально но конкретно в этом случае лучше вынести в сигнал либо вообще в селери

Спасибо за наводку

У тебя должен быть отдельный контейнер с базой к которой ты будешь подрубаться с двух сторон

Не думаю что так всё просто. Пробую готовый модуль для этого дела

ну я сонный был =) потом прикинул что как минимум нужно держать актуальными модели в обоих приложениях как выход выносить в отдельный git модуль

https://github.com/jbittel/django-mama-cas Пока что это нашел

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

Чото мне кажется там иначе работает

остается проблема то все таблицы будут хранится в одной базе, это если по простому если по сложному то разные базы с роутингом в настройках orm

Чото мне кажется там иначе работает

что именно ?

Обмен данными о юзере между приложениями

обмена не будет, так как база одна

Но я только предполагаю. Будем посмотреть

Вот я не уверен что одна база.

Или ты точно знаешь?

это я про то что я предложил выносить базу в контейнер и конектиться с обоих приложений к одной базе

Понял. А я про этот готовый вариант

=)

мне кажется мой вариант проще

Похоже этот модуль еще не прикрутили ко второму джанге

мне кажется мой вариант проще

Ну не факт что удобней

Смотря какая ситуация

Смотря какая ситуация

тут да

@dantyan ты спишь хоть когда-нибудь?)

бывает

Но не часто, видимо

незаметно я бы сказал =)

https://github.com/applegrew/django-select2

Я заметил, что поиск там не регистрозависимый и для русского языка. А можно ли реализовать с его помощью поиск не только внутри модели, но и по моделям? Скажем по пользователям.

Я заметил, что поиск там не регистрозависимый и для русского языка. А можно ли реализовать с его помощью поиск не только внутри модели, но и по моделям? Скажем по пользователям.

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

queryset переопределить?

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

Просто я использую sqlite db и для обычного search_fields поиск регистрозависимый, вот мне и интересно, можно ли обойти это с помощью django select, чтобы не ставить mysql.

Просто я использую sqlite db и для обычного search_fields поиск регистрозависимый, вот мне и интересно, можно ли обойти это с помощью django select, чтобы не ставить mysql.

Если коротко, любой опытный разработчик скажет что скулайт для более менее серьезных проектов не подходит, поэтому в любом случае надо перейти на посттре (ну или на мускуль - если хочеться поизвращаться)

Так что я бы начал с этого вместо велосипедостроений над пакетами

Привет коллеги! Вопрос тем, кто api делает. Как нормально CSFR токен передать с другого домена? Использую corsheaders, django-rest-fraemwork, в настройках что только не пробовал, сейчас стоит CORS_ORIGIN_ALLOW_ALL = True CSRF токен передаю через GET запрос, потом вставляю в cookie на фронте и отправляю с POST запросом в заголовке: X-CSRFToken:eaeeFIRm1lXmGwCXfcV1HGdmFjnZhJkJ9qMfB5DHgv2syx96S65SQWeFI5Bh0Etq но получаю CSRF cookie not set.

Тогда всё таки поставлю MySQL, спасибо.

csrf же как раз защита от cross-domain:)