Я не понимаю разницы между ADD и SET. Есть подсказки? Кажется, что ADD включает SET или что ADD возвращает false, если что-то есть, а SET просто перезаписывает. Спасибо!
РЕДАКТИРОВАТЬ: Мой конкретный вопрос: «Когда вы используете добавить, а не установить или установить, а не добавить?»
У вас уже есть почти ответ на свой первый вопрос: цель ADD должен работать только тогда, когда ключ еще не существует, а SET нужно ли обновлять значение, независимо от того, существует ли оно уже. Если вы знакомы с SQL, это (примерно) похоже на разницу между INSERT запросы (ADD) и UPDATE (SET).
Что касается вашего дополнительного вопроса, вы должны использовать тот, который подходит для ваших целей. Я бы сказал, что SET будет более распространенной операцией, потому что чаще всего вы просто хотите сказать "Я хочу ключ foo иметь ценность bar, и меня не волнует, был ли он там уже ». Однако будут (менее частые) случаи, когда необходимо знать, что ключа еще нет в кеше.
На ум приходит пример, когда ADD было бы целесообразно хранить сеансы в кэше памяти (что, кстати, я не рекомендую) - если вы генерируете идентификаторы сеансов случайным образом (или с помощью хеширования), вы не захотите создавать новый сеанс с тот же ключ, что и существующий, так как это предоставит одному пользователю доступ к данным другого пользователя. В этом случае при создании сеанса вы должны использовать ADD, и если он вернул статус сбоя, вам нужно будет сгенерировать новый идентификатор сеанса и повторить попытку. При обновлении сеанса, конечно, будет использоваться SET когда пользователь прошел через ваше приложение.
В дополнение к приведенному выше ответу по идентификатору пользователя 'womble', обратите внимание на следующие моменты:
Возможность состояние гонки с "установить", а не с "добавить". См. Ссылку ниже на ответ Ника Джонсона: https://stackoverflow.com/questions/13234556/using-memcache-add-instead-of-set
Если вы знаете, что подойдет «добавить», не используйте «набор». Это для Избегайте отправки данных по сети, поскольку это вызовы RPC. И практически все время тратится на сетевой трафик, а не на поиск пары ключ-значение в кэше памяти. Так что, если вы можете избежать сетевого трафика, это лучше всего, поскольку в этом случае время ответа будет быстрее.
См. Appstats (https://developers.google.com/appengine/docs/python/tools/appstats (Google)) и чтобы лучше понять пункт 2 выше, просмотрите http://www.youtube.com/watch?v=bvp7CuBWVgA Автор: Гвидо Ван Россум (@Google)