[
https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639180#comment-16639180
]
Josh Elser commented on RATIS-279:
----------------------------------
{code:java}
+ switch (logServiceRequestProto.getRequestCase()) {
+ case LOGMESSAGE:
<snip/>
+ case CREATELOG:
+ return processCreateLogRequest(logServiceRequestProto);
+ case LISTLOGS:
+ return processListLogsRequest();
+ case GETLOG:
+ return processGetLogRequest(logServiceRequestProto);
+ case GETSTATE:
+ return processGetStateRequest(logServiceRequestProto);
+ case ARCHIVELOG:
+ return processArchiveLog(logServiceRequestProto);
+ case CLOSELOG:
+ return processCloseLog(logServiceRequestProto);
+ case DELETELOG:
+ return processDeleteLog(logServiceRequestProto);
+ default:
+ return null;{code}
Any chance we can convert this into some kind of Visitor pattern in which we
can rely on the argument type to dispatch this to the right method? (and avoid
the massive enum)
{code:java}
diff --git
a/ratis-logservice/src/test/java/org/apache/ratis/logservice/TestLogServiceWithGrpc.java
b/ratis-logservice/src/test/java/org/apache/ratis/logservice/TestLogServiceWithGrpc.java
new file mode 100644
index 0000000..f7219b0
--- /dev/null
+++
b/ratis-logservice/src/test/java/org/apache/ratis/logservice/TestLogServiceWithGrpc.java
@@ -0,0 +1,7 @@
+package org.apache.ratis.logservice;
+
+import org.apache.ratis.grpc.MiniRaftClusterWithGrpc;
+
+public class TestLogServiceWithGrpc extends
LogServiceBaseTest<MiniRaftClusterWithGrpc>
+ implements MiniRaftClusterWithGrpc.FactoryGet {
+}{code}
This might be a "bigger" thing than just down here in log service, but it would
be nice for Ratis to provide a base test class that uses the JUnit
Parameterized feature instead of forcing us to create "empty" classes like this
to test netty and grpc support. Maybe I spin this out into a new Jira issue?
{code:java}
+ case CREATELOG:
+ return processCreateLogRequest(logServiceRequestProto);
+ case LISTLOGS:
+ return processListLogsRequest();
...
+ case GETSTATE:
+ return processGetStateRequest(logServiceRequestProto);
+ case ARCHIVELOG:
+ return processArchiveLog(logServiceRequestProto);
+ case CLOSELOG:
+ return processCloseLog(logServiceRequestProto);
+ case DELETELOG:
+ return processDeleteLog(logServiceRequestProto);{code}
These would eventually be going to a the "metadata service", right? So, these
will eventually be lifted into a different state machine. Might make it easier
to transition if we have an interface for these methods (might also help avoid
conflicts with Vlad). What do you think?
> Create administrative API for a log stream
> ------------------------------------------
>
> Key: RATIS-279
> URL: https://issues.apache.org/jira/browse/RATIS-279
> Project: Ratis
> Issue Type: Sub-task
> Components: LogService
> Reporter: Josh Elser
> Assignee: Rajeshbabu Chintaguntla
> Priority: Major
> Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch,
> RATIS-279_v3.patch, RATIS-279_v4.patch, RATIS-279_v5.patch
>
>
> We need to do basic things like:
> * List all log streams
> * Delete a log stream
> * Truncate a log stream
> This may overlap with functionality that actually should live in HBase.
> Making that distinction is part of the tasks of this issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
