а Вы точно имели ввиду ctypes? Ведь это просто модуль для подключения внешних библитек (.so, .dll)?
Вероятно инересна разница между написанием модуля, например, на Cython и чистом С?
В зависимости от реализации tmpstore.
FileUploadTempStore это ж только интерфейс. В том примере, что выше, вообще используется dict и никакого файла на диске нет вообще, все в памяти.
Думаю, Вам вполне подойдет реализация SessionFileUploadTempStore из pyramid_deform либо прийдется писать свой.
However, the deform.FileUploadWidget does not remove data from the tempstore implementation it uses (it doesn’t have enough information to be able to do so), and it is job of the tempstore implementation itself to expire items which haven’t been accessed in a while.
А чего вы пытаетесь добиться, чтоб в один attrib нельзя было добавить 'b', который равен 'a'?
По-поводу ensureIndex, не вижу ни единой причины постоянно его вызывать, кроме как «случайно забыл создать раньше » или «кто-то постоянно удалят мои индексы».
Почему советуют на форумах не ясно, может они пишут причину?
Или заглянули б в исходники, что там на самом деле происходит (псевдокод):
function ensureIndex(params):
if __internal_index_cache.exists(params):
return
else:
collection.create_index(params)
Отдельный индекс на каждый attrib.key прийдется делать только если надо раздельно проверять наличие каждого из ключей. Но тогда неважно, что именно проверять, тип или само значение, все равно пришлось бы делать отдельные индексы. А если a и b вместе, то составной индекс вполне подойдет.
По-поводу потери смысла, ничего сказать не могу, очень мало данных о задаче. Может там вообще без $exists можно обойтись как-то. Да и странно по-моему, что только из-за индекса, массив станет лучше документов.
Ну в таком случае попробовать стоит конечно.
А самый простой вариант, вероятно таки, с использованием UTL_TCP — строчек в 10 уложитесь, я думаю.
Удачи!
Так оракл же и сам неплохо кеширует частые запросы.
Если таблица небольшая, то она и так вероятно будет в кеше (ну или частые запросы).
Можно попробовать поиграться с настройками кеширования, чтоб нужные результаты из него не выпадали.
Либо сделать кеш побольше или таблицу покомпактнее. Или поместить в индекс все нужные поля.
Или сделать materialized view только с актуальными данными.
Вообщем от характера данных зависит конечно сильно.
Но по-моему, в любом случае лучше сначала попробовать имеющиеся у оракла средства для оптимизации, чем добавлять еще одну неочевидно работающую прослойку.
Ну дело тут не в php/python вообщем-то, а в том, что автор пытается один placeholder заменить несколькими значениями, что естественно не выходит. (Разве что, кроме %s, какой-то списковый placeholder есть, в чем я очень сомневаюсь)
А варианта, по-моему, всего два, либо ваш либо предыдущий. Т.е. или задачу экранирования значений положить на плечи mysql или доверять своему списку id и генерировать сразу правильный SQL
Ну тут же вся сложность, как я понимаю, отсеять строки с ненужными словами. Может быть вторая часть (которая NOT REGEXP) получится довольно простая и быстрая. Вероятно даже будет просто NOT REGEXP «слово3|слово4» или вообще NOT LIKE «слово3» AND NOT LIKE «слово4»
Если же таблица большая и скорость важна, то может стоит попробовать добавить отдельную колонку/таблицу в качестве индекса
Но вообще да, надо еще подумать
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Вероятно инересна разница между написанием модуля, например, на Cython и чистом С?