[
https://issues.apache.org/jira/browse/RATIS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16622233#comment-16622233
]
Josh Elser commented on RATIS-317:
----------------------------------
{quote}Why do we need that? Moreover, that would mean that we have to
reconstruct the Entry using HBase API and that would : 1) affect the
performance which is already far from the ideal 2) make it HBase version
depended. And how all that information is related to the abstract log service
we are building? The particular Ratis based HBase WAL may have some internal
state machine that would track something like meta information for the cluster,
but that's a completely different story, isn't it?
{quote}
Extracting/maintaining information about the data in the Log would be a pretty
neat idea that I think would be generally reusable across applications. Say we
were storing a list of values read from a sensor – we could be pushing down
things like min, max, stddev, etc. I am totally hand-waving when it comes to
how we would let users build their own aggregations – just trying to point out
at this point that having an easily expressed aggregation for data in the log
strikes me as something pretty cool.
{quote}As a stakeholder I eager to see a working POC earlier than later :)
{quote}
PS, running a build with v3 now. +1 for that version from me :)
> Log service state machine
> -------------------------
>
> Key: RATIS-317
> URL: https://issues.apache.org/jira/browse/RATIS-317
> Project: Ratis
> Issue Type: Sub-task
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
> Attachments: RATIS-317-v1.patch, RATIS-317-v2.patch,
> RATIS-317-v3.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
