Питон не совсем мой язык.
Правильно ли я понял код, если в нём счастливые комбинации формируются сразу все для указанной разрядности номера и системы счисления?
Как тогда в вашем варианте реализовать последовательный постраничный вывод большого количества счастливых комбинация для, например, билетов с номерами длиной более 50 знаков?
> Этап III. Операционные системы
> Шаг 1
> Таненбаум «Архитектура компьютера»
> Шаг 2
> Колисниченко, Аллен «Linux: полное руководство»
> От общей теории переходим к изучению конкретной операционной системы – на примере Linux.
> Немет, Снайдер, Хейн «Руководство администратора Linux»
Всё-таки, на этом этапе, когда человек ещё не знаком с программированием, я бы не стал давать Таненбаума, ибо Таненбаум больше рассматривает ОС с точки зрения её разработки, что будет интереснее много позже. Для изучения логики работы и архитектуры ОС я бы посоветовал Вильям Столлингс — Операционные системы. Достаточно хорошо и структурированно.
Кроме того, руководство администратора Linux — больше для сисадминов, нежели программистов. Основ ОС вполне хватит на этом этапе, а к управлению и программированию под конкретные ОС можно было бы вернуться позже.
И Smart Window, и телевизор с Smart Interaction напомнили недавно просмотренный английский сериал Black Mirror, а точнее его 2-ой эпизод («15 Million Merits»), в котором действие происходит в будущем, с экранами повсюду, с управлением посредством жестов и т.п.
Идея сериала, конечно, немного обратная, но тоже заслуживаем внимания.
Хотя иметь ES8000 дома для кино и Smart Window для работы я бы был не против. :) Дождёмся, когда появятся у нас.
Спасибо за отзыв.
Согласен, такие места часто могут появляться при работе с хранилищем данных.
Хоть вероятность появления подобных глюков небольшая, но при увеличении нагрузки и их появлении отловить и понять их становится проблематичным — было дело, уже сталкивались.
По приведённому примеру: последствия глюка в принципе не критичны (кеш используется с небольшим TTL, поэтому через некоторое время всё равно сбросится и данные станут актуальными), и не будут явными для конечных пользователей. Спасибо за подсказку с append и cas. Подумаем, потестируем и попытаемся внедрить, хотя стандартный класс Zend_Cache_Backend_Memcached в ZF это не поддерживает — будем его расширять.
Конечно, в перспективе хотелось бы обеспечить большую стабильность. Не подскажите, какие еще варианты в этом случае возможны? Ведь подобные проблемы (борьба за ресурсы и параллельное выполнение кода) могут возникнуть много где, в том числе и в нашем коде.
Возможен и другой вариант:
Если результирующий объект, содержащий имя и адрес, собирается сразу из нескольких таблиц (через join), то в этом случае изменение адреса является изменением параметров объекта, и для класса этого объекта во всех методах, где идёт сохранение изменённых параметров в БД, должна вызываться очистка кеша для сохраняемого объекта.
Изначально алгоритм предназначен для кеширования данных каждой модели (таблицы) отдельно (без join'ов). Сделано так в связи с установкой, что join'ы между большими таблицами с динамическими данными — дело медленное, поэтому их лучше избегать.
Но при желании можно развить и для более сложных ситуаций, включая join'ы.
Насколько я Вас понял, в Вашем примере делаются два отдельных запроса (один за именем, один за адресом). Если делать их с join'ами, но использовать для кеширования разные базовые модели (в первом случае — модель таблицы с именем, во втором — модель таблицы с адресом), то при изменении адреса должны будут удалиться из кеша все записи для объекта с адресом. Таким образом при следующем запросе адреса информация в кеше найдена не будет и пройдёт новый запрос в БД на получение обновлённых данных.
(Уточню, что тег для объекта строится на основе имени таблицы и первичного ключа объекта в БД.)
Спасибо за ссылку. Изучим.
Реализованный наш метод отличается отсутствием необходимости явно указывать тег при сохранении в кеш. Что тоже может быть полезным в различных случаях.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Правильно ли я понял код, если в нём счастливые комбинации формируются сразу все для указанной разрядности номера и системы счисления?
Как тогда в вашем варианте реализовать последовательный постраничный вывод большого количества счастливых комбинация для, например, билетов с номерами длиной более 50 знаков?
> Шаг 1
> Таненбаум «Архитектура компьютера»
> Шаг 2
> Колисниченко, Аллен «Linux: полное руководство»
> От общей теории переходим к изучению конкретной операционной системы – на примере Linux.
> Немет, Снайдер, Хейн «Руководство администратора Linux»
Всё-таки, на этом этапе, когда человек ещё не знаком с программированием, я бы не стал давать Таненбаума, ибо Таненбаум больше рассматривает ОС с точки зрения её разработки, что будет интереснее много позже. Для изучения логики работы и архитектуры ОС я бы посоветовал Вильям Столлингс — Операционные системы. Достаточно хорошо и структурированно.
Кроме того, руководство администратора Linux — больше для сисадминов, нежели программистов. Основ ОС вполне хватит на этом этапе, а к управлению и программированию под конкретные ОС можно было бы вернуться позже.
Идея сериала, конечно, немного обратная, но тоже заслуживаем внимания.
Хотя иметь ES8000 дома для кино и Smart Window для работы я бы был не против. :) Дождёмся, когда появятся у нас.
Согласен, такие места часто могут появляться при работе с хранилищем данных.
Хоть вероятность появления подобных глюков небольшая, но при увеличении нагрузки и их появлении отловить и понять их становится проблематичным — было дело, уже сталкивались.
По приведённому примеру: последствия глюка в принципе не критичны (кеш используется с небольшим TTL, поэтому через некоторое время всё равно сбросится и данные станут актуальными), и не будут явными для конечных пользователей. Спасибо за подсказку с append и cas. Подумаем, потестируем и попытаемся внедрить, хотя стандартный класс Zend_Cache_Backend_Memcached в ZF это не поддерживает — будем его расширять.
Конечно, в перспективе хотелось бы обеспечить большую стабильность. Не подскажите, какие еще варианты в этом случае возможны? Ведь подобные проблемы (борьба за ресурсы и параллельное выполнение кода) могут возникнуть много где, в том числе и в нашем коде.
Если результирующий объект, содержащий имя и адрес, собирается сразу из нескольких таблиц (через join), то в этом случае изменение адреса является изменением параметров объекта, и для класса этого объекта во всех методах, где идёт сохранение изменённых параметров в БД, должна вызываться очистка кеша для сохраняемого объекта.
Но при желании можно развить и для более сложных ситуаций, включая join'ы.
Насколько я Вас понял, в Вашем примере делаются два отдельных запроса (один за именем, один за адресом). Если делать их с join'ами, но использовать для кеширования разные базовые модели (в первом случае — модель таблицы с именем, во втором — модель таблицы с адресом), то при изменении адреса должны будут удалиться из кеша все записи для объекта с адресом. Таким образом при следующем запросе адреса информация в кеше найдена не будет и пройдёт новый запрос в БД на получение обновлённых данных.
(Уточню, что тег для объекта строится на основе имени таблицы и первичного ключа объекта в БД.)
Реализованный наш метод отличается отсутствием необходимости явно указывать тег при сохранении в кеш. Что тоже может быть полезным в различных случаях.