Lagom persistEntityRegistry.register не работает

Я пытаюсь настроить свою первую сущность с помощью Cassandra и Lagom.

Я спрашиваю о том, как Лагом спасает сущность в Кассандре?

Например, это мой класс UserServiceImpl:

public class UserServiceImpl implements UserService {

    private final PersistentEntityRegistry persistentEntityRegistry;

    @Inject
    public UserServiceImpl(PersistentEntityRegistry persistentEntityRegistry) {
        this.persistentEntityRegistry = persistentEntityRegistry;
        persistentEntityRegistry.register(UserEntity.class);
    }

    @Override
    public ServiceCall<NotUsed, String> getUserInfo(String id) {
        return (request) -> {
            // Look up the user entity for the given ID.
            PersistentEntityRef<UserCommand> ref = persistentEntityRegistry.refFor(UserEntity.class, id);
            // Ask the entity the Hello command.
            return ref.ask(new UserCommand.Hello(id, Optional.empty()));
        };
    }
}

Итак, выполнив:

persistEntityRegistry.register(UserEntity.class);

Должен ли я иметь таблицу пользователей в Cassandra? потому что у меня есть только:

введите здесь описание изображения

Я не могу понять, должен ли я создать пользователя таблицы перед запуском моего проекта Lagom или мы только сохраняем событие?

Любая помощь, пожалуйста


java cassandra lagom
person Imen    schedule 08.12.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Lagom не требует таблицы для объекта, потому что он не основан на объектно-реляционном отображении или чем-то подобном. Его уровень сохраняемости основан на принципах Event Sourcing.

Таблица сообщений будет содержать события, генерируемые вашей сущностью, и ее состояние восстанавливается каждый раз, когда вы возвращаете ее в память.

В основном события сохраняются в формате json в таблице сообщений.

У нас также есть концепция моментальных снимков. Состояние объекта может быть сохранено в виде моментального снимка (также с использованием json). Это происходит после каждых 100 событий, и это небольшая оптимизация, позволяющая избежать повторного воспроизведения событий с нуля каждый раз.

Я постараюсь кратко объяснить весь механизм.

Команда отправляется объекту, и события сохраняются (это происходит в обработчике команд). После сохранения событий они применяются к объекту для его изменения (это происходит в обработчике событий).

Вы перезапускаете службу и отправляете новую команду тому же объекту. В этот момент объект не находится в памяти, поэтому Лагом перенесет его в память, но перед обработкой этой новой команды он воспроизведет историю событий для этого объекта, чтобы вернуть его в состояние, в котором оно было, когда система вышла из строя.

После этого команда применяется и новые события сохраняются.

После 100 событий будет сохранен снимок объекта, и в следующий раз, когда потребуется воспроизвести тот же объект, мы сначала загрузим снимок, а затем применим события, которые произошли после снимка. Таким образом, в этом случае нам не нужно воспроизводить всю историю событий.

person Renato    schedule 08.12.2017
comment
Спасибо, Ренато, и извини за опоздание. Я это понимаю, и теперь это более ясно. Но в то же время мы можем манипулировать сущностями, реализуя постоянную сторону чтения. Итак, если рекомендуются Event Sourcing и CQRS, когда мне следует использовать сторону чтения? у вас есть рекомендации по этому поводу? - person Imen; 18.12.2017
comment
Идея состоит не в том, чтобы манипулировать сущностями на стороне чтения. Сторона чтения предназначена для создания представлений и любых представлений, которые вы можете получить из событий. - person Renato; 19.12.2017