Github user choang commented on the pull request:
https://github.com/apache/storm/pull/705#issuecomment-147967734
`StateStore` implementations could be designed like:
```
public class KafkaStateStore implements StateStore {
public KafkaStateStore(HostPort kafkaBroker, String consumerId) { //
consumerId could be topic? I'm don't know enough about the compaction feature
...
}
...
}
public class ZkStateStore implements StateStore {
public ZkStateStore(HostPort zkConnect, String path) {
...
}
}
// future implementations
public class JdbcStateStore implements StateStore {
public JdbcStateStore(String url, String stateTable, String user,
String password) {
...
}
}
public class MemoryStateStore implements StateStore {
public MemoryStateStore() {
...
}
}
```
What I'm trying to illustrate are two factors:
1) go away from `StormConf` and `SpoutConfig` because `StateStore` does not
need all properties of either objects.
2) the concrete implements of `StateStore` do not need to have the same
constructor because your goal is not to have a factory and make it completely
config driven. You want to make it so the topology developer can decide what
`StateStore` to use.
With the above, it would be pretty easy for someone to implement
`MemoryStateStore` and `JdbcStateStore`.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
