Pull to refresh
24
0
Влад Старостин @savados

User

Send message
Занятно то, что чтобы она произошла, нужно добавить в словарь больше элементов, чем в нем было. Иначе никак.
Занятно, что удаление элементов из словаря не приводит к уменьшению таблицы:

In [1]: d = dict.fromkeys(range(9999))

In [2]: d.__sizeof__()
Out[2]: 786680

In [3]: for k in xrange(9999):
   ...:       del d[k]
   ...:     

In [4]: d.__sizeof__()
Out[4]: 786680

Но в данном случае переменная var передаётся в шаблон slave.html неявно — var передатся в master.html, а slave.html просто «цепляет» контекст master'а. Таким образом, мы видим, что шаблон внутри {% include %} зависит от контекста основного шаблона. Мы вынуждены следить за контекстом родительского шаблона, иначе в дочерний может попасть что-нибудь не то.

Решается параметром only:

If you want to render the context only with the variables provided (or even no variables at all), use the only option. No other variables are available to the included template:
{% include "name_snippet.html" with greeting="Hi" only %}
И? Если стоимость одного запроса в два раза больше стоимости другого запроса, это не значит, что первый запрос будет выполняться в два раза медленней. Можно неоптимально прописать эти константы, и никакой зависмости не будет. Что я пытаюсь сказать уже второй комментарий.

единица измерения осталась та же

А если в seq_page_cost прописать 3.14, то какой, по-вашему, будет единица измерения?
Не граничит оно никак со временем. Cost зависит от количества операций и их условной стоимости (planner cost constants). Эти константы, по уму, должны зависеть от особенностей машины, где работает постгрес (например, random_page_cost — разная для разных типов дисков, а effective_cache_size зависит от количества доступной памяти). В результате из всех возможных планов выбирается план с наименьшей стоимостью. А время тут ни при чем.

В принципе, при грамотном выставлении planner cost constants теоретически можно добиться того, что cost будет прямо пропорционален затраченному времени, но сама по себе эта связь не обязательна.
Неясно, почему бы не сделать нормальный перевод. Зачем выкидывать кучу деталей из статьи, ориентированной на новичков? Один пример:

Такой запрос будет исполняется реально. Так что если вы выполняете EXPLAIN (ANALYZE) для INSERT или UPDATE, ваши данные изменятся. Будьте внимательны! В таких случаях используйте команду ROLLBACK.

Во-первых, без оборачивания в транзакцию от ROLLBACK не будет никакого толка, а во-вторых, ни слова про команду DELETE. Она не изменит данные что ли? Конечно, вещи очевидные, но не для новичков же. А не новички ничего нового не узнают (и им тем более нужны детали). В оригинале, при этом, все ок.

Или еще: «width — средний размер одной строки». В попугаях? Опять надо лезть в оригинал (там все ок).

Сколько строк будет считывать ANALYZE — зависит от параметра default_statistics_target.

В оригинале — 300*default_statistics_target. Четкая и простая зависимость.

Неясно, зачем портить статьи. Советую всем прочитать оригинал.

Ну может быть (хотя как он на эту страницу попадет, введет URL руками?). Плюс, таких ситуаций должно быть несколько, тогда подобная заготовка декоратора будет иметь смысл.
В Джанге уже есть user_passes_test. Поэтому ваш should_be_anonymous реализуется одной строчкой.

@user_passes_test(lambda u: u.is_anonymous(), login_url=reverse_lazy('my_view_name'))
def some_view(request, *args, **kwargs):
    pass


(Хотя имя login_url здесь выбрано не очень удачно).

Какие еще условия, кроме проверки пользователя, можно привязать к request, я не могу придумать. О, можно проверять метод HTTP, например допускать только POST. Но Джанга у тут уже обо всем позаботилась.
Этот тег отлично наследуется, так что достаточно одного раза в базовом шаблоне. Но даже если вы уверены, что middleware чище, почему бы не использовать django.utils.html.strip_spaces_between_tags, зачем писать эту логику самостоятельно?
Хм, а в чем именно сомнительность? Всегда был уверен, что куча маленьких узкоспециализированных аппов лучше одного монструозного.

Еще, по поводу StripWhitespace middleware. Чем {% spaceless %} не угодил?
Зачем все это в одном пакете? Почему не в нескольких? Вообще же никакой связности.
Если функция load_template ничего не найдет, то она зачем-то вернет строку из одного пробела. Которая приведется к True, а не к False, как, видимо, ожидал автор.

Рекомендуется к прочтению.
Если проще, то так

module, file = t.split(":", 1)
Можно пару примеров, какие задачи поможет решить «умение программировать»?
Хорошая статья для Робинзона, вернувшегося в цивилизацию.
Пользуясь случаем, рекомендую хорошую книжку по теме.
Так инвалидация будет удобней, но станет более «жадной», о чем и сам автор пишет.

For example if you update a post in a particular category, this strategy will expire all the keys for all the categories.


Чаще всего это нежелательно. Хотя, можно группировать ключи более «гранулярно». Впервые я услышал о подобном подходе к организации ключей в этой прекрасной презентации.
Что ещё нужно-то? :-)

Я приводил пример в посте. Часто, если в обработчике сигнала created == True, можно не инвалидировать часть ключей. Например, условно, топ100 статей за все время, свежесозданная статья туда не попадет. Есть и еще ряд проверок, которые могут оказаться очень полезными, чтобы не делать сложные выборки.

И я не утверждаю, что это нужно всегда. Но что это есть, знать стоит, и учитывать при выборе подхода к кэшированию тоже стоит.

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

Немного не о том. Я про то, что часто лучше заменить cache.delete(key) на cache.set(key, instance), если instance передается в сигнал.

В целом, спор кажется бесперспективным. Я же не говорю: не используйте готовое, пишите все сами, только хардкор и т. д. У готовых решений есть некоторые ограничения. Если они критичны (или есть какие-то другие причины), то можно рассмотреть возможность реализации кэша самостоятельно. Если не критичны, конечно, используйте готовое. Только и всего.
Не очень понимаю, как это закрывает пост. К этому приложению применимы все те же две претензии:
  • Недостаточный контроль за инвалидацией: можно инвалидировать объект, можно инвалидировать все объекты модели, больше ничего.
  • Ограничения, возможно, потребующие дополнительного кода (раздел Caveats)


Плюс, инвалидация только через удаление записи в кэше, что не всегда является лучшим решением (о чем я пишу в посте).

Приложение хорошее, да, не хуже тех, что перечислены в посте, но у меня не было цели сделать обзор всех готовых решений. Так что может рано пока закрывать? :-)
Мы, наверное, немного о разном говорим. Я хочу сказать, что все потребители классической музыки не были гиками. Большинство из них ходило в оперы и балеты для того же, зачем сейчас большинство ходит в кино — приятно провести время. И уж точно не большинство аристократов помешивалось на музыке, а разорялись единицы.

Про крестьян тут вообще непонятно к чему, они не были потребителями классической музыки. Это как пользователи IDE: гики используют Вим и Емакс, а остальные программисты что-то более мейнстримовое. При этом большая часть населения Земли вообще не в теме, но это не меняет расклада.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity