Хм, не все так просто. Если открыть википедию, мы увидим, что Historically, the term has also been used as a geographical, cultural, and later religious identifier for people living in the Indian subcontinent.
В действительности видеть разными глазами разное — это удел многих профессий, связанных с оптикой. Астрономы, фотографы, микробиологи,
Около года ходил в группу спортивной стрельбы по движущейся мишени из пневматики. Тренировался почти ежедневно, даже получил какой-то разряд — на КМС не хватило ни выдержки, ни времени. У нас прицел — специальная 4-х кратная оптика, и все стрелки не закрывают левый глаз при стрельбе. Так что подтверждаю:)
PUT: будет использоваться для обновления существующего ресурса.
Частичный PUT нарушает спецификацию HTTP. Он предназначен для полной замены ресурса, а не для обновления. В чем-то сродни операции присваивания. Для частичных обновлений подходит или POST, или PATCH из RFC 5789.
Без финального присваивания эквивалент не будет работать для иммутабельных типов вроде int, str, tuple, frozenset etc где вместо модификации создается копия.
Воу, благодарю за развернутый текст. Я отвечу по мере своего опыта.
Хуже, не 1/2, а скорее 1/4 размера страницы. Причина в том, что в "простом" b+tree в branch-странице должно быть минимум 2 ключа и для возможности эффективного split+rebalance это правило должно выполняться после разделения страницы пополам. Соответственно 2*2 = 4.
Howard Chu писал, что Keys must be small enough to fit on a page, and a page must contain at least two keys in order for the B-tree structure to be maintained. So the absolute max is 1/2 the page size; we use 1/3 to avoid size issues when using DUPSORT mixed with other data.https://bugzilla.redhat.com/show_bug.cgi?id=1086784#c5
Нет смысла делать вложенными читающие транзакции, они будут читать одно и тоже и ничего не могут менять. При необходимости такая вложенность может эмулироваться кодом-оберткой со счетчиком ссылок, но ценность и сценарии использования такой возможности (мне) не понятны.
Прекрасно это понимаю, но это неудобно. Так, я не могу абстрагировавшись создать "сверху" родительскую транзакцию (например, в декораторе) и просто передать ее в подчиненную функцию. Мне нужно знать, пишет ли код "снизу" или только читает.
Сквозная нумерация конечно была-бы полезна (например для быстрой оценки range-запросов). Но Howard не стал её реализовывать (видимо) потому, что этого НЕ требовалось в его целевых сценариях (OpenLDAP), но требовало еще больше усложнить исходный код.
Это было вообще киллер-фичей для меня. Молниеносная пагинация и вычисление total по диапазону BTree только один из примеров.
Технически очередь (FIFO или с приоритетами) тривиально реализуется поверх key-value. В случае LMDB при этом в качестве ключа можно использовать номер транзакции (если требуется FIFO), а в MDBX также есть генераторы последовательностей.
Да. Верно. Но технически это не будет дотягивать до DB_QUEUE в Berkeley DB. Во-первых,
процесс может ожидать следующую запись с помощью DB_CONSUME_WAIT, не требуя постоянного опроса БД. В противном случае придется делать опрос и сигнализацию (через ZMQ или сырой UDP-мультикаст). Во-вторых, репликация очереди происходит специальным образом: put реплицируется, а consume — нет (поэтому реплики тоже могут делать локальный consume). Наконец, очередь легко заоптимизировать. В Berkeley DB очереди работают с огромной скоростью.
Если же требуется "тупая" очередь в виде максимально эффективного FIFO с полной durability, то специализированные решения на базе кольцевых буферов будут все равно эффективнее.
Но мы не сможем делать операции с внешней очередью и базой данных атомарно.
Однако, если это тянуть в key-value движок хранения, то снова получится "швейцарский нож", но не действительно надежный охотничий или удобный перочинный.
Проблемы с надежностью у Berkeley DB вызваны главным образом из-за её хрупкой подсистемы блокировок, которая требует внешнего разрешения дедлоков и восстановления. Для DB_BTREE дедлоки иногда возникают вообще by design.
Кастомный компаратор все равно проиграет memcmp. Так что самое быстро решение — сериализовать составной ключ в строку, поддерживающую правильный порядок при лексикографическом сравнении.
В свое время я из интереса написал универсальный сериализатор ключей LRE когда работал с Berkeley DB, поскольку аналогичных библиотек в сети я не нашел. Сериализатор из FDB не позволяет сравнивать целые и флоаты, потому что использует для них разные представления.
При всех достоинствах LMDB (главным образом астрономическая скорость), существует много ограничений, особенно если сравнивать с её "медленным старшим братом" Berkeley DB. Вот некоторые из тех, с которыми я сталкивался:
Длина ключа ограничена 511 байтами. Этот #define внутри библиотеки может быть переопределён, но его значение не может быть больше, чем 1/2 размера страницы
Только пишущие транзакции могут быть вложенными. Родительские транзакции не могут выполнять никаких операций кроме mdb_txn_commit и mdb_txn_abort. Вложенные транзакции несовместимы с MDB_WRITEMAP
Курсоры не имеют возможностей эффективного смещения, только последовательная перемотка записей или MDB_SET_RANGE
А насколько мы знаем в url при REST подходе мы должны использовать исключительно ресурсы, но не роли (не исключаю, что тут я уже сам себя передумал)
Ни REST, ни спецификации URI и HTTP не ограничивают сферу того, что может быть отнесено к "ресурсам". Ресурс — всего лишь цель гиперссылки, любой адресуемый концепт вписывается в это понятие. Даже сервис или действие могут быть адресованы URI.
> Например есть версия, что слово «кейс» повышает читаемость блога и поднимает карму употребляющему его, ибо пихается куда только можно.
Есть ли короткая и полноценная замена?
Случай, сценарий, дело, пример, обстоятельства, что угодно) Бывает, что пишут какой-нибудь леденящий душу п*здец вроде «ваш пойнт невалиден» когда точка зрения оппонента ошибочна. На мой взгляд, добрая половина англицизимов вызвана баззвордингом, банальным желанием примазаться к ИТ-тусовке.
JWT токены не стоит НИКОГДА отзывать. Они не задумывались для отзыва.
Совершенно верно. Если чувствуется необходимость в отзыве, вам определенно не нужен JWT. Если вас не устраивает протухание данных в 10 минут — то же самое.
JWT по определению предназначен для хранения кэшированных данных на стороне клиента, поэтому наследует все проблемы кеширования вроде инвалидации или несогласованности.
Это выигрыш в производительности за счет безопасности. В любом случае даже короткий TTL — это "слепой период", на протяжении которого мы будем доверять любым устаревшим данным в JWT. В любом случае нам нужна stateful-инфраструктура для refresh-токенов, при этом мы по-прежнему не сможем отозвать JWT в любое время.
В моих книжках написано, что not (not x) = x для всех допустимых x, значит, None эквивалентно not (not None).
Ещё раз. У вас не получится сложить None и 1. Оператор not это логический оператор отрицания, который возвращает строго True/False. Двойное инвертирование True вернёт True и наоборот, эта цепочка из not not not [...] может быть бесконечной. Не понимаю, что мы обсуждаем?
Сначала None автоматически преобразуется в bool, потом bool автоматически преобразуется в int.
Типичная слабая типизация.
Оператор not возвращает True или False. Тип bool унаследован от int, поэтому в арифматическом смысле True всегда равен 1, а False всегда равен 0. У вас не получится сделать None + 1.
Установил и с тех пор пользуюсь как в знак поддержки проекта, призванного возродить концепцию классической Opera, так и просто как хорошим браузером.
Между прочим, правила MISRA C тоже запрещают malloc/calloc/free.
Хм, не все так просто. Если открыть википедию, мы увидим, что
Historically, the term has also been used as a geographical, cultural, and later religious identifier for people living in the Indian subcontinent.
Понятно, что "индиец". Но код — индусский :)
Desing by buzzword, упомянутый Филдингом в начале своей диссертации. Как в воду глядел)
Интересно, почему тогда такие API не называются CRUD API?
Около года ходил в группу спортивной стрельбы по движущейся мишени из пневматики. Тренировался почти ежедневно, даже получил какой-то разряд — на КМС не хватило ни выдержки, ни времени. У нас прицел — специальная 4-х кратная оптика, и все стрелки не закрывают левый глаз при стрельбе. Так что подтверждаю:)
Частичный PUT нарушает спецификацию HTTP. Он предназначен для полной замены ресурса, а не для обновления. В чем-то сродни операции присваивания. Для частичных обновлений подходит или POST, или PATCH из RFC 5789.
Без финального присваивания эквивалент не будет работать для иммутабельных типов вроде int, str, tuple, frozenset etc где вместо модификации создается копия.
Выражение
является буквальным эквивалентом этого:
Воу, благодарю за развернутый текст. Я отвечу по мере своего опыта.
Howard Chu писал, что Keys must be small enough to fit on a page, and a page must contain at least two keys in order for the B-tree structure to be maintained. So the absolute max is 1/2 the page size; we use 1/3 to avoid size issues when using DUPSORT mixed with other data. https://bugzilla.redhat.com/show_bug.cgi?id=1086784#c5
Прекрасно это понимаю, но это неудобно. Так, я не могу абстрагировавшись создать "сверху" родительскую транзакцию (например, в декораторе) и просто передать ее в подчиненную функцию. Мне нужно знать, пишет ли код "снизу" или только читает.
Это было вообще киллер-фичей для меня. Молниеносная пагинация и вычисление total по диапазону BTree только один из примеров.
Да. Верно. Но технически это не будет дотягивать до DB_QUEUE в Berkeley DB. Во-первых,
процесс может ожидать следующую запись с помощью DB_CONSUME_WAIT, не требуя постоянного опроса БД. В противном случае придется делать опрос и сигнализацию (через ZMQ или сырой UDP-мультикаст). Во-вторых, репликация очереди происходит специальным образом: put реплицируется, а consume — нет (поэтому реплики тоже могут делать локальный consume). Наконец, очередь легко заоптимизировать. В Berkeley DB очереди работают с огромной скоростью.
Но мы не сможем делать операции с внешней очередью и базой данных атомарно.
Проблемы с надежностью у Berkeley DB вызваны главным образом из-за её хрупкой подсистемы блокировок, которая требует внешнего разрешения дедлоков и восстановления. Для DB_BTREE дедлоки иногда возникают вообще by design.
Кастомный компаратор все равно проиграет memcmp. Так что самое быстро решение — сериализовать составной ключ в строку, поддерживающую правильный порядок при лексикографическом сравнении.
В свое время я из интереса написал универсальный сериализатор ключей LRE когда работал с Berkeley DB, поскольку аналогичных библиотек в сети я не нашел. Сериализатор из FDB не позволяет сравнивать целые и флоаты, потому что использует для них разные представления.
При всех достоинствах LMDB (главным образом астрономическая скорость), существует много ограничений, особенно если сравнивать с её "медленным старшим братом" Berkeley DB. Вот некоторые из тех, с которыми я сталкивался:
Ни REST, ни спецификации URI и HTTP не ограничивают сферу того, что может быть отнесено к "ресурсам". Ресурс — всего лишь цель гиперссылки, любой адресуемый концепт вписывается в это понятие. Даже сервис или действие могут быть адресованы URI.
https://tools.ietf.org/html/rfc3986#section-1.1
https://tools.ietf.org/html/rfc7231#section-2
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_1
Есть ли короткая и полноценная замена?
Случай, сценарий, дело, пример, обстоятельства, что угодно) Бывает, что пишут какой-нибудь леденящий душу п*здец вроде «ваш пойнт невалиден» когда точка зрения оппонента ошибочна. На мой взгляд, добрая половина англицизимов вызвана баззвордингом, банальным желанием примазаться к ИТ-тусовке.
Совершенно верно. Если чувствуется необходимость в отзыве, вам определенно не нужен JWT. Если вас не устраивает протухание данных в 10 минут — то же самое.
JWT по определению предназначен для хранения кэшированных данных на стороне клиента, поэтому наследует все проблемы кеширования вроде инвалидации или несогласованности.
Это выигрыш в производительности за счет безопасности. В любом случае даже короткий TTL — это "слепой период", на протяжении которого мы будем доверять любым устаревшим данным в JWT. В любом случае нам нужна stateful-инфраструктура для refresh-токенов, при этом мы по-прежнему не сможем отозвать JWT в любое время.
Ещё раз. У вас не получится сложить None и 1. Оператор not это логический оператор отрицания, который возвращает строго True/False. Двойное инвертирование True вернёт True и наоборот, эта цепочка из not not not [...] может быть бесконечной. Не понимаю, что мы обсуждаем?
Оператор not возвращает True или False. Тип bool унаследован от int, поэтому в арифматическом смысле True всегда равен 1, а False всегда равен 0. У вас не получится сделать
None + 1.Просто использую Vivaldi в надежде на то, что они все-таки сделают браузер уровня Opera Presto)