Maybe that would be more intuitive than PositionAwareSubscriptionModel? So instead of:
// Create the non-durable subscription instance
PositionAwareSubscriptionModel nonDurableSubscriptionModel = ...
// Create the storage
SubscriptionPositionStorage storage = ...
// Now combine the non-durable subscription and the subscription position storage
SubscriptionModel durableSubscriptionModel =
new DurableSubscriptionModel(nonDurableSubscriptionModel, storage);
// Start a subscription
durableSubscriptionModel.subscribe(
"mySubscriptionId",
cloudEvent -> doSomethingWithTheCloudEvent(cloudEvent)
);
we would have:
// Create the non-durable subscription instance
NonDurableSubscriptionModel nonDurableSubscriptionModel = ...
// Create the storage
SubscriptionPositionStorage storage = ...
// Now combine the non-durable subscription and the subscription position storage
SubscriptionModel durableSubscriptionModel =
new DurableSubscriptionModel(nonDurableSubscriptionModel, storage);
// Start a subscription
durableSubscriptionModel.subscribe(
"mySubscriptionId",
cloudEvent -> doSomethingWithTheCloudEvent(cloudEvent)
);
Alternatlivey: TransientSubscriptionModel.
Think about how we would support some DB that holds the checkpoint as a part of the user? Then it is a DurableSubscriptionModel, but it can't use the same class (but we could create an interface though) since it takes an instead of SubscriptionPositionStorage.
Maybe that would be more intuitive than
PositionAwareSubscriptionModel
? So instead of:we would have:
Alternatlivey:
TransientSubscriptionModel
.Think about how we would support some DB that holds the checkpoint as a part of the user? Then it is a
DurableSubscriptionModel
, but it can't use the same class (but we could create an interface though) since it takes an instead ofSubscriptionPositionStorage
.