本文深入探讨了在使用DynamoDB Mapper扫描数据时遇到的`DynamoDBMappingException`，特别是当模型中包含自动生成的时间戳（`Long`类型）但数据库中存在`String`类型的时间戳数据时。文章分析了错误原因，提供了诊断和解决数据类型不一致问题的策略，强调了数据一致性在DynamoDB应用开发中的重要性。
在使用AWS SDK for Java的DynamoDB Mapper进行数据操作时，DynamoDBMappingException是一个常见的错误，它通常表示应用程序的数据模型与DynamoDB中存储的实际数据结构之间存在不一致。具体到“expected N in value {S: 2022-12-09T09:23:52.737Z,}”这样的错误信息，其含义是：Mapper期望在名为timestamp的属性中找到一个Number类型（N），但实际从数据库中读取到的却是一个String类型（S），其值为“2022-12-09T09:23:52.737Z”。
这通常发生在以下场景：
当DynamoDBMapper尝试将从DynamoDB获取的String类型数据反序列化到Employee对象中预期的Long类型timestamp字段时，就会抛出DynamoDBMappingException。
考虑以下Employee模型定义：
@Data
@AllArgsConstructor
@NoArgsConstructor
@DynamoDBTable(tableName = "employee")
public class Employee {
@DynamoDBHashKey
@DynamoDBAutoGeneratedKey
private String employeeId;
// ... 其他属性
@DynamoDBAutoGeneratedTimestamp(strategy = DynamoDBAutoGenerateStrategy.ALWAYS)
private Long timestamp; // 期望为Long类型
}这里，timestamp字段被定义为Long类型，并且@DynamoDBAutoGeneratedTimestamp注解指示DynamoDB Mapper在保存时自动生成一个Long类型的时间戳。
DynamoDbConfiguration配置如下：
@Configuration
public class DynamoDbConfiguration {
@Bean
public DynamoDBMapper dynamoDBMapper() {
return new DynamoDBMapper(buildAmazonDynamoDB());
}
private AmazonDynamoDB buildAmazonDynamoDB() {
return AmazonDynamoDBClientBuilder
.standard()
.withEndpointConfiguration(
new AwsClientBuilder.EndpointConfiguration(
"endpoint",
"region"
)
)
.withCredentials(
new AWSStaticCredentialsProvider(
new BasicAWSCredentials(
"access_key",
"secret_key"
)
)
)
.build();
}
}获取所有员工的方法：
public List<Employee> getAllEmployees() {
return dynamoDBMapper.scan(Employee.class, new DynamoDBScanExpression());
}当执行getAllEmployees()方法时，如果employee表中存在任何一条记录，其timestamp属性存储为字符串（如"2022-12-09T09:23:52.737Z"），而不是数字（如1670577832737L），就会触发上述的DynamoDBMappingException。
要解决此问题，首先需要确认数据不一致性。
检查DynamoDB表数据：
通过限制扫描范围进行初步验证： 如果表数据量较大，不便手动检查，可以尝试修改扫描方法，限制返回的项目数量，以快速定位问题是否出在早期记录：
public List<Employee> getLimitedEmployees(int limit) {
DynamoDBScanExpression scanExpression = new DynamoDBScanExpression()
.withLimit(limit); // 限制返回数量
return dynamoDBMapper.scan(Employee.class, scanExpression);
}调用getLimitedEmployees(1)，如果仍然报错，则说明第一条记录可能就有问题。如果不再报错，则问题可能出在后续记录。
解决DynamoDBMappingException的关键在于确保DynamoDB中存储的数据类型与应用程序模型期望的类型完全一致。
主要策略：更新DynamoDB中的不一致数据。
由于Employee模型期望timestamp为Long（通常是UNIX纪元毫秒），你需要将DynamoDB中所有String类型的timestamp值转换为Long类型的数字。
手动纠正（适用于少量数据）：
批量脚本纠正（推荐，适用于大量数据）： 对于大量不一致的数据，编写一个临时的Java或Python脚本来遍历表并更新这些记录更为高效。
Java示例（使用AWS SDK）：
import com.amazonaws.services.dynamodbv2.AmazonDynamoDB;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClientBuilder;
import com.amazonaws.services.dynamodbv2.document.*;
import com.amazonaws.services.dynamodbv2.document.spec.ScanSpec;
import com.amazonaws.services.dynamodbv2.document.utils.ValueMap;
import java.time.Instant;
import java.time.format.DateTimeParseException;
import java.util.Iterator;
public class TimestampCorrection {
private static final String TABLE_NAME = "employee";
public static void main(String[] args) {
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard()
// .withEndpointConfiguration(new AwsClientBuilder.EndpointConfiguration("http://localhost:8000", "us-east-1")) // For local DynamoDB
// .withCredentials(...) // Configure credentials if not using default
.build();
DynamoDB dynamoDB = new DynamoDB(client);
Table table = dynamoDB.getTable(TABLE_NAME);
ScanSpec scanSpec = new ScanSpec()
.withProjectionExpression("employeeId, #ts") // 只获取主键和时间戳
.withNameMap(new NameMap().with("#ts", "timestamp")); // 映射保留字
try {
ItemCollection<ScanOutcome> items = table.scan(scanSpec);
Iterator<Item> iterator = items.iterator();
while (iterator.hasNext()) {
Item item = iterator.next();
String employeeId = item.getString("employeeId");
Object timestampValue = item.get("timestamp");
if (timestampValue instanceof String) {
String stringTimestamp = (String) timestampValue;
try {
// 尝试将字符串时间戳解析为Long (UNIX纪元毫秒)
long epochMilli = Instant.parse(stringTimestamp).toEpochMilli();
// 更新项目
UpdateItemOutcome outcome = table.updateItem(
"employeeId", employeeId,
new AttributeUpdate("timestamp").put(epochMilli)); // 将String更新为Number
System.out.println("Updated item " + employeeId + ": timestamp from '" + stringTimestamp + "' to " + epochMilli);
} catch (DateTimeParseException e) {
System.err.println("Skipping item " + employeeId + ": Could not parse timestamp string '" + stringTimestamp + "' as ISO 8601. Error: " + e.getMessage());
// 处理无法解析的字符串，可能需要手动干预
} catch (Exception e) {
System.err.println("Error updating item " + employeeId + ": " + e.getMessage());
}
} else if (timestampValue instanceof Number) {
// 已经是Number类型，无需处理
// System.out.println("Item " + employeeId + ": timestamp is already a Number.");
} else if (timestampValue == null) {
System.out.println("Item " + employeeId + ": timestamp is null.");
// 根据业务需求决定是否需要为null的timestamp设置一个默认值
}
}
} catch (Exception e) {
System.err.println("Error scanning table: " + e.getMessage());
} finally {
client.shutdown();
}
}
}注意事项：
DynamoDBMappingException中的“expected N in value {S: ...}”错误清晰地指出了应用程序模型与DynamoDB实际数据之间的类型不匹配。特别是对于像@DynamoDBAutoGeneratedTimestamp这样的自动生成属性，应用程序通常期望其为Long类型。解决此问题的核心在于识别并纠正DynamoDB表中所有不符合模型期望的数据项。通过数据检查、批量更新和遵循严格的数据写入最佳实践，可以有效避免此类映射异常，确保DynamoDB应用的稳定性和数据一致性。
以上就是解决DynamoDB映射异常：类型不匹配与自动生成时间戳字段的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
602
收藏
