Я прочитал ветку Как установить ключ диапазона DynamoDB, String или Map . Однако, подумав, я подумал о большем.
Я использую Джексона для сериализации и десериализации объекта в весеннем приложении. Это приложение было создано кем-то другим, и теперь оно в моей руке, чтобы улучшить его после его первого выпуска.
Существует 2 варианта создания ключа раздела:
- Использовать разделитель (например, value1 # value2)
- сериализация в JSON (например, {"field1": "value1", "field2": "value2"})
Разделитель-подход:
Если я использую разделитель, я могу создать разделитель, который вряд ли (в моем случае) будет отображаться как часть значения1 или значения2. Этот подход будет генерировать более короткую строку, чем при использовании Джексона. Также в официальной документации DynamoDB приведен пример с таким подходом.
Однако этот подход означает, что мне нужно документировать порядок и правила. В случае, если другие приложения (например, Node-based или Go используют ту же базу данных), я должен сказать им, чтобы они читали документы.
Джексон-подход:
Если я использую Джексона, это вполне документируется, я могу использовать @JsonFormat для обеспечения согласованности форматирования, я могу использовать @JsonFilter, чтобы выбрать поля, которые я хочу сериализовать для этого случая. Я могу использовать @JsonProperty для сокращения имени поля (хотя я сомневаюсь, что мне понадобится сократить имя поля), а также реализация будет более надежной.
Но опять же, в моем случае уже есть таблица, в которой уже реализован подход с разделителями. Это означает, что в документации приложения должно быть написано два разных формата. Также я думаю, что генерация ключей должна быть очень явной.
Я немного профессионал в подходе с разделителями для согласованного форматирования, но с другой стороны, я мог бы упустить или не увидеть хорошие вещи от подхода Джексона, особенно в будущем при разработке этого проекта.
У меня вопрос: должен ли я использовать разделитель или другой подход?