UDFRegistration.register
поставляется в вариантах, которые принимают:
UserDefinedFunction
UDF0
, UDF1
, ..., UDF22
, например для бинарных функций :
def register(name: String, f: UDF2[_, _, _], returnType: DataType): Unit
Scala Function0
, Function1
, ..., Function22
например для бинарных функций
def register[RT, A1, A2](name: String, func: (A1, A2) ⇒ RT)(implicit arg0: scala.reflect.api.JavaUniverse.TypeTag[RT], arg1: scala.reflect.api.JavaUniverse.TypeTag[A1], arg2: scala.reflect.api.JavaUniverse.TypeTag[A2]): UserDefinedFunction
[1128 ] Не существует варианта, который принимает имя класса. Ваш код не терпит неудачу при компиляции только потому, что String
в Scala
равно (Int) => Char
, поэтому соответствует
def register[RT, A1](name: String, func: (A1) ⇒ RT)(implicit arg0: scala.reflect.api.JavaUniverse.TypeTag[RT], arg1: scala.reflect.api.JavaUniverse.TypeTag[A1]): UserDefinedFunction
Но это, конечно, не то, что вы имеете в виду.
no-store
should not be necessary in normal situations, and can harm both speed and usability. It is intended for use where the HTTP response contains information so sensitive it should never be written to a disk cache at all, regardless of the negative effects that creates for the user.
How it works:
Normally, even if a user agent such as a browser determines that a response shouldn't be cached, it may still store it to the disk cache for reasons internal to the user agent. This version may be utilised for features like "view source", "back", "page info", and so on, where the user hasn't necessarily requested the page again, but the browser doesn't consider it a new page view and it would make sense to serve the same version the user is currently viewing.
Using no-store
will prevent that response being stored, but this may impact the browser's ability to give "view source", "back", "page info" and so on without making a new, separate request for the server, which is undesirable. In other words, the user may try viewing the source and if the browser didn't keep it in memory, they'll either be told this isn't possible, or it will cause a new request to the server. Therefore, no-store
should only be used when the impeded user experience of these features not working properly or quickly is outweighed by the importance of ensuring content is not stored in the cache.
My current understanding is that it is just for intermediate cache server. Even if "no-cache" is in response, intermediate cache server can still save the content to non-volatile storage.
This is incorrect. Intermediate cache servers compatible with HTTP 1.1 will obey the no-cache
and must-revalidate
instructions, ensuring that content is not cached. Using these instructions will ensure that the response is not cached by any intermediate cache, and that all subsequent requests are sent back to the origin server.
If the intermediate cache server does not support HTTP 1.1, then you will need to use Pragma: no-cache
and hope for the best. Note that if it doesn't support HTTP 1.1 then no-store
is irrelevant anyway.
Originally we used no-cache many years ago and did run into some problems with stale content with certain browsers... Don't remember the specifics unfortunately.
We had since settled on JUST the use of no-store. Have never looked back or had a single issue with stale content by any browser or intermediaries since.
This space is certainly dominated by reality of implementations vs what happens to have been written in various RFCs. Many proxies in particular tend to think they do a better job of "improving performance" by replacing the policy they are supposed to be following with their own.
При определенных обстоятельствах IE6 по-прежнему будет кэшировать файлы, даже если в заголовках ответа указано Cache-Control: no-cache
.
Если директива no-cache не работает укажите имя поля, затем кеш НЕ ДОЛЖНЫ использовать ответ для удовлетворения последующий запрос без успешного повторная проверка с исходным сервером.
В моем приложении, если вы посетили страницу с заголовком no-cache
, затем вышли из системы, а затем вернулись в свой браузер, IE6 все равно захватит страницу из кеш (без нового / проверяющего запроса к серверу). Добавление в заголовок no-store
остановило его выполнение. Но если вы поверите W3C на слове, на самом деле нет никакого способа контролировать это поведение:
Буферы истории МОГУТ хранить такие ответы как часть своей нормальной работы.
Описываются общие различия между историей браузера и обычным HTTP-кешированием. в конкретном подразделе спецификации .
Из спецификации HTTP 1.1 :
no-store :
Целью директивы no-store является для предотвращения непреднамеренного выпуска или сохранения конфиденциальной информации (например, на лентах с резервными копиями). Директива no-store применяется ко всему сообщению и МОЖЕТ быть отправлена либо в ответе, либо в запросе. Если отправлено в запросе, кэш НЕ ДОЛЖЕН хранить какую-либо часть этого запроса или любого ответа на него. При отправке в ответе кэш НЕ ДОЛЖЕН хранить какую-либо часть этого ответа или запроса, который его вызвал. Эта директива применяется как к общим, так и к общим кешам. «НЕ ДОЛЖЕН хранить» в этом контексте означает, что кэш НЕ ДОЛЖЕН намеренно хранить информацию в энергонезависимой памяти, Даже если эта директива связана с ответом, пользователи могут явно сохранить такой ответ вне системы кэширования (например, с помощью диалогового окна «Сохранить как»). Буферы истории МОГУТ хранить такие ответы как часть своей нормальной работы. Цель этой директивы - удовлетворить заявленные требования определенных пользователей и авторов сервисов, которые обеспокоены случайным выпуском информации из-за непредвиденного доступа к структурам данных кеширования. Хотя использование этой директивы может в некоторых случаях улучшить конфиденциальность, мы предупреждаем, что это ни в коем случае НЕ является надежным или достаточным механизмом для обеспечения конфиденциальности. В частности, вредоносные или скомпрометированные кеши могут не распознавать эту директиву или не подчиняться ей, а сети связи могут быть уязвимы для подслушивания.
Если вы хотите предотвратить все кеширование (например, принудительно перезагрузить при использовании кнопки возврата), вам необходимо:
no-cache для IE
no-store для Firefox
Вот моя информация об этом:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
Чтобы еще больше усугубить ситуацию, в некоторых ситуациях нельзя использовать no-cache, но no-store можно:
http://faindu.wordpress.com/2008 / 04/18 / ie7-ssl-xml-flex-error-2032-stream-error /