atLeastOnce parameters

[patriknw]

The CassandraProjection.atLeastOnce maybe has too many parameters to be convenient?
We could remove saveOffsetAfterElements and saveOffsetAfterDuration and place them in configuration.

Then have a builder style api to define them programmatically. atLeastOnce would then return AtLeastOnceCassandraProjection extends CassandraProjection which has the additional withSaveOffsetAfterElements and withSaveOffsetAfterDuration.

CassandraProjection.atLeastOnce(
  projectionId,
  sourceProvider,
  offsetExtractor) { env => ... }
  . withSaveOffsetAfterElements(100)
  . withSaveOffsetAfterDuration(1.second)

Probably not nice with the handler as second parameter list, but we talked about making the handler a trait instead of a function and then it will not be a second parameter list.

[octonato]

I often prefer a builder approach because fluent APIs are really good for discoverability even when we pay the cost of writing a few inner stage classes.

We can even close the builder with the event handler (function or trait) and builds the final projection.

[seglo]

If we create a Settings object then they could be more easily reused with multiple projections. That's what's done in Alpakka Kafka. The settings objects have defaults that can be overridden using typesafe config or at runtime using builder-pattern APIs.

[patriknw]

Settings are good for general configuration, but here it was about parameters that are specific to a method, and are not used for other methods. atLeastOnce vs atMostOnce.

[octonato]

Can we then pass a strategy instance, for example:

CassandraProjection(
  projectionId,
  sourceProvider,
  AtLeastOnce(100, 1.second),
  handler)

and

CassandraProjection(
  projectionId,
  sourceProvider,
  AtMostOnce,
  handler)

[octonato]

Or maybe we prefer build style?

CassandraProjection(
  projectionId,
  sourceProvider,
  handler).atLeastOnce(100, 1.second)

and

CassandraProjection(
  projectionId,
  sourceProvider,
  handler).atMostOnce

[octonato]

Now that the handler isn't a function anymore, it doesn't need to be the last in the list, and we can close the builder by declaring how we want to treat the commits.

[patriknw]

I think the builder is not better than what we have. Builders are great for optional parameters, but these are mandatory choices.

I don't think the strategy is easier to use, not as nice for IDE code completion. Additionally, very few will use atMostOnce.

I have some experiments for grouping lying around and I think we need to add that to the mix before deciding here.

[octonato]

I have some experiments for grouping lying around and I think we need to add that to the mix before deciding here.

Looking forward to it

[patriknw]

Or we move the two parameters for atLeastOnce to config (ProjectionSettings). Don’t think they will tuned much per projection.

[octonato]

I understood that your idea is that those are mandatory parameters, like method arguments, and therefore should not be on the settings.

Moreover, the settings are good for all projections, not only for at-least-once

[patriknw]

Yes, that was my initial thinking, but it should be possible to have default that normally works and then it can be tuned if needed instead.

[octonato]

But then in that case we will have at-least-once settings that are exposed at API level, but maybe be useless. Like when using atMostOnce or jdbc exactlyOnce.

[octonato]

Unless we return a AtLeastOnceProjection that has the methods withSaveOffsetAfterElements and withSaveOffsetAfterDuration in addition to withSettings

[patriknw]

yes, that's nice. Defaults from config and possibility to amend.

[seglo]

Implemented in #175