Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Inter-Dactor Message Type Hierarchy #97

Open
srfc opened this issue Jul 11, 2018 · 0 comments
Open

Refactor Inter-Dactor Message Type Hierarchy #97

srfc opened this issue Jul 11, 2018 · 0 comments

Comments

@srfc
Copy link
Collaborator

srfc commented Jul 11, 2018

Refactor Inter-Dactor Message Type Hierarchy

Refactor the type hierarchy of inter-Dactor messages to improve flexibility when processing messages using pattern matching as well as to make them more manageable.

Problem Description

  • Pattern matching messages within Receive methods is not very flexible because of a flat hierarchy of most message types
  • Unsafe messages that are only meant for use in debugging or testing do not share a common ancestor and might be hard to keep track of so we can later warn or deprecate them for production use

Supporting Information

  • Possible type hierarchy layout with a focus on improving specificity to support flexible pattern matching:
Root class Childs Description
akka.actor.Status Success, Failure Messages from the akka-framework
InternalMessageProtocol. InternalMessage Ping, Pong, UpdateMapping, ... Messages used internally in the adbms framework.
DefaultMessageProtocol. Status InsertIntoRelation. Success|Failure, SelectAllFromRelation. Success|Failure Unsafe messages, only used for testing, debugging and not meant for production.
RequestResponseProtocol. Response <UserOp>.Success|Failure, ... Production-grade messages defined by the developer (user of our framework). We only provide the base classes.
  • RequestResponseProtocol is already on master

Related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant