длиннее типа больше букав? ))

да, это же время разработки

соответственно, дороже

на го лучше делать то, что требует скорости

очень странная оценка трудозатрат )) ну да ладно - пусть так будет

хайлоад так называемый

ну конечно не стоит очередной вордпресс писать на го

для этого есть сам вордпресс

не трудозатрат, а времязатрат

хотя чем черт не шутит ))

вордпресс - другая весовая категория)

эт да!

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

итерпритатор с компилятором )))

Ребят, у нас тут django, мы, вроде как, определились уже. Че обсуждать.

не создавать же отдельный канал для полчасового диалога)

не создавать же отдельный канал для полчасового диалога)

уже есть pyflood

уже есть pyflood

о, блэкстар тоже кодеры))

у меня такой вопрос. есть готовая огромная база данных на постгрес. и web applicatiin которая делает операции вывода или ввода данных на эту базу. и я должен создать пользователей и дать им привелегию. над какой баз данных это сделать ? на sqlite (тот который стоит в django который ничего не делает) или в постгрес (сделав ее основным)

Если я сделаю эту базу основным . В админке все ли таблицы будут показаны после миграции ? Просто там очень огромная база

можете помочь новичку ?)

В админке показываются зарегистрированные модели а не таблицы бд

Подскажите, если я добавляю related_items, то в результате в базу данных делается только один дополнительный запрос в котором запрашивается целиком вся таблица указанная в related_items ?

или все равно на каждую строку основной таблицы делается свой запрос к внешней таблице?

И если запрашивается вся таблица целиком... то она дейстительно вся целиком запрашивается или только те строки, которые есть во внешних ключах моего основного объекта (к которому я указываю) realted_items

Короче говоря, есть возможность, что-то оптимизировать, сделав вручную все операции надо объектом, или related_items делает все итак максимально правильно и хорошо? Сомнения у меня возникли, потомучто, всего на 300 строках, в которых есть внешний ключ на табличку с 5ью строками я вижу заметное снижение быстродействия... (POSTGRESS использую).

Фиг знает. Как вариант: select и prefetch_related не используют ранее кэшированные данные и лезут в базу каждый раз заново.

[OrderAdditional.objects.create(product=i, order=order) for i in cart.products] А так не надо делать, да? Джанга m2m through field

Entry.objects.bulk_create([ Entry(headline='This is a test'), Entry(headline='This is only a test'), ])

Фиг знает. Как вариант: select и prefetch_related не используют ранее кэшированные данные и лезут в базу каждый раз заново.

зато база смотрит в свой кеш

И используется всего один запрос

? Ура. Надо бы на такой случай бота написать

Убрано)

Короче говоря, есть возможность, что-то оптимизировать, сделав вручную все операции надо объектом, или related_items делает все итак максимально правильно и хорошо? Сомнения у меня возникли, потомучто, всего на 300 строках, в которых есть внешний ключ на табличку с 5ью строками я вижу заметное снижение быстродействия... (POSTGRESS использую).

если посмотреть в debug toolbar, то можно увидеть, что select_related выглядит как JOIN в sql, а prefetch_related - это отдельный запрос с фильтром id IN [тут список idов]. Если есть снижение быстродействия, и подозрение на базу данных, то стоит включить debug_toolbar (или ловить запросы через logginпg, там есть логгер с запросами) и убедиться, что select_related/prefetch_related прописаны верно.

если посмотреть в debug toolbar, то можно увидеть, что select_related выглядит как JOIN в sql, а prefetch_related - это отдельный запрос с фильтром id IN [тут список idов]. Если есть снижение быстродействия, и подозрение на базу данных, то стоит включить debug_toolbar (или ловить запросы через logginпg, там есть логгер с запросами) и убедиться, что select_related/prefetch_related прописаны верно.

в debug_toolbare я вообще не заметил разницу запроса с помощи select_related и без

perfetch_related тоже

очень странно. А сервер перезагружался после изменения исходного кода?

очень странно. А сервер перезагружался после изменения исходного кода?

вы мне?

Хм, подскажите с Celery пожалуйста. Мне нужно запускать в celery команду взаимодействующая с Django orm. Когда запускаю получаю ошибку от psql django.db.utils.OperationalError: FATAL: password authentication failed for user "user" FATAL: password authentication failed for user "user"

и что не понятно?

Почему celery не может взаимодействовать с базой и как дать ему доступ? Само Django приложение нормальное работает

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'PROJ.settings') в celery.py

import os from celery import Celery from celery.schedules import crontab os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings') app = Celery('proj') app.config_from_object('django.conf:settings', namespace='CELERY') app.autodiscover_tasks()

На том же хосте целери?

Да, на локалке тестю.

Кажется понял ошибку

Если поставить proj.settings_local то работает. Из-за разных файлов конфигов проблема..

Так в settings.py try: from settings_local import * except ImportError: pass

кто-то юзал django-el-pagination? и кто может показать исходник с ajax'ом

кто-то юзал django-el-pagination? и кто может показать исходник с ajax'ом

Было дело, делал по http://django-el-pagination.readthedocs.io/en/latest/digg_pagination.html#adding-ajax

Но таки не доделали, так как переписали фронт на вью

у питона ваще какое то туманное будущее(имхо) - как ни грустно. На мелочи пыхыпы все займет что то серьезнее будет на го/раст/ и что то урвет мелкогомякий с яблоками. Уже щас с вакансиями на питоне не так круто - только папки нужны в отличии от других упомятых ЯП (сори за сопли - чето придавило)

нет ни 1 языка программирования в мире, на котором было бы быстрее и проще писать прототипы)

нет ни 1 языка программирования в мире, на котором было бы быстрее и проще писать прототипы)

Ruby?

он мёртв уже

Но таки не доделали, так как переписали фронт на вью

О! Это интересно - через REST?

Ruby живой и очень даже юзается многими

он мёртв уже

?

на Ruby Puppet, RoR живые, что ещё?

вот хипстерский nim

все живые ушли с Ruby на Elixir

вон рокет банк на ruby сидит))

он мёртв уже

На западе половина стартапов пишется на RoR. Хотя сейчас все уже на node.js и go, наверное, перешли.

Nim норм, но там нет инфраструктуры как у питона

с руби на нод - вот этого мне не понять )))

ERROR: S client not available

на go тупо больше кода, чем на Python'е

RoR недавно обнова вышла. но не думаю, что он начнет опять популярность набирать)

На западе половина стартапов пишется на RoR. Хотя сейчас все уже на node.js и go, наверное, перешли.

а на питоне?

кто из России, у вас много вакансий на ГО?

go хорош для сисадминов

в других нишах он не имеет преимуществ

сетевой стек на go норм

кто из России, у вас много вакансий на ГО?

да кто ж их считал ))

на go тупо больше кода, чем на Python'е

может наоборот ? а баш хорош для виндузятников ? Где логика ?

ахахахах

да кто ж их считал ))

ну в Украине щас 9 штук висит

против пайтона 76

на самом деле go много где хорош

и джавы ~200

может наоборот ? а баш хорош для виндузятников ? Где логика ?

если писать тот же самый код на питоне и на го - на го будет длиннее программа

что плохо

против пыхи мильен)))

если писать тот же самый код на питоне и на го - на го будет длиннее программа

зато исходник и никаких зависимостей

а разве это мешает?

сейчас всё в контейнерах

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

и на Kubernetes

у админов О_о

против пыхи мильен)))

у нас дотнет пока рвет, 300вак

Там половина PHP, Python или что-нибудь ещё. Если на HH поискать Python там половина вакансий будет на Java/.NET, где знание питона просто как плюсик в резюме.

сейчас деплоят контейнерами

пых чуть меньше

бинарники/код уже не отдают

отдают образы контейнеров

на минуточку сам докер на го написан )))