У меня есть следующая таблица:
- атрибут 1
- атрибут 2
- атрибут 3
- атрибут 4 -> ключ дедупликации
- атрибут 5 -> состояние
- UUID.
И сервис, построенный на основе этого для CRUD.
Начальное состояние элемента - «активный». Если вызывается CRUD API createItem, мне нужно проверить, присутствует ли уже элемент с таким же состоянием de-dupe key и 'active', если да, мне нужно изменить этот элемент, или создать новый элемент для того же ключ с активным состоянием.
У меня не может быть GSI на ключе дедупликации, и я могу обеспечить одиночный характер. Когда приложение записывает или удаляет элементы в таблице, любые глобальные вторичные индексы в этой таблице обновляются асинхронно, используя в конечном итоге непротиворечивую модель. '
Однако есть и другие способы достижения этого:
Иметь другую таблицу с ключом дедупликации (в качестве первичного ключа) и активным элементом UUID в качестве единственного атрибута. Таким образом, DAO взаимодействует с обеими таблицами для взаимодействия. Это болезненно, поскольку DAO имеет дело с 2 таблицами (обработка атомарности может быть затруднена).
Имейте de-dupe в качестве PK и метку времени в качестве ключа сортировки. За исключением активного элемента, оставьте отметку времени 0. И выполняйте ее условные обновления, пока не изменится ее состояние. Но при таком подходе я потеряю способность выполнять batchLoad / batchGet для UUID, поскольку ключом de-dupe является PK.
Любые идеи приветствуются. Спасибо.