[
https://issues.apache.org/jira/browse/CASSANDRA-17103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602315#comment-17602315
]
Benedict Elliott Smith commented on CASSANDRA-17103:
----------------------------------------------------
Regarding {{TxnOperation}} you name the variables {{scope}} so it would make
sense to include {{Scope}} in the interface name, though I tend to find words
like {{Operation}} and {{Scope}} and {{Context}} are very generic and hard to
follow for readers. I don't currently have any better ideas though.
I'm just looking at the use cases, though, and as far as I can tell _most_
implementations only involve a single {{txnId}} while a couple ({{Command}} and
{{LocalRead}}) involve many via their {{deps}}. Since I think it highly likely
we will eventually treat the {{deps}} differently in this respect (as we are
just going to be registering listeners, or checking if they have applied) we
might want to consider separating these into two methods perhaps? This would
also permit the majority of use cases to avoid allocating wrapper objects,
simply returning an empty list for {{deps}}?
> CEP-15 (C*): Messaging and storage engine integration
> -----------------------------------------------------
>
> Key: CASSANDRA-17103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17103
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord
> Reporter: Benedict Elliott Smith
> Assignee: Blake Eggleston
> Priority: Normal
> Fix For: 5.x
>
>
> This work encompasses implementing Accord’s storage and networking interfaces
> within Cassandra, so that messages may be sent around the cluster and
> exectuted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
