我在基于Eclipse的JSF项目中有一个War and Jar项目.我已经决定使用注释来声明我的FacesConverter(在众多其他事物中),而不是使用我的faces-config.xml声明它.
@FacesConverter(value="passwordFieldStringConverter")
public class PasswordFieldStringConverter implements Converter {
public Object getAsObject(FacesContext arg0, UIComponent arg1, String arg2) throws ConverterException {
try {
return arg2.getBytes("UTF-16BE");
}
catch(UnsupportedEncodingException uee) {
Assert.impossibleException(uee);
}
return(null);
}
public String getAsString(FacesContext arg0, UIComponent arg1, Object arg2) throws ConverterException {
try {
return new String((byte[]) arg2, "UTF-16BE");
}
catch(UnsupportedEncodingException uee) {
Assert.impossibleException(uee);
}
return(null);
}
}
然后我直接在我的.xhtml中使用passwordFieldStringConverter:
<?xml version="1.0" encoding="UTF-8" ?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:sec="http://www.springframework.org/security/facelets/tags">
<ui:composition>
<f:view>
<f:loadBundle basename="landingPage.bundle" var="bundle" />
<ui:decorate …Amazon 的 DynamoDB 文档似乎对如何为行选择分区刻意保持谨慎。这是关于分区键的讨论（重点是我的）：
\n\n\n分区键 \xe2\x80\x93 一个简单的主键，由一个称为分区键的属性组成。
\nDynamoDB 使用分区键的值作为内部哈希函数的输入。哈希函数的输出确定将存储项目的分区（DynamoDB 内部的物理存储）。
\n在只有一个分区键的表中，任何两个项目都不能具有相同的分区键值。
\n表、项目和属性
\nPeople中描述的表是具有简单主键 ( ) 的表的示例。您可以通过提供该项目的值来立即访问表中的任何项目。PersonIDPeoplePersonId
因此，给出的示例将 PersonID 作为数字，对于散列来说，该数字可能很大，也可能很差 - 取决于内部散列函数。
\n在我的项目中，我们使用随机 v4 UUID 作为主键，目前我们以字符串/S形式保留该 UUID（包含破折号）。我发现，与整数类似，这个 UUID 字符串可以根据内部哈希函数进行漂亮或惨淡的哈希处理。
将 UUID 保留为字符串对我们来说很方便（尽管浪费空间），因为我们可以在 Dynamo 控制台中以与应用程序日志中显示的相同 v4 格式查看/查询 UUID。但是，如果以 String/S形式而不是 Binary/ 形式保存我们的 UUIDB形式保存我们的 UUID 将导致我们的行可怕地别名为一两个分区，因为内部哈希函数将我们的 UUID 字符串转换为字节是天真的，那么便利性就该死了Binary/B形式最适合 UUID。
因此，我想了解有关内部哈希函数的更多信息（最好是来自 Dynamo 开发人员本身）。请向我们提供有关该内部哈希函数的智能程度的详细信息。S它与 String/ 、 Number/N和 …
hash performance amazon-web-services database-partitioning amazon-dynamodb