Add ETS table rendering to Kino.Process.{sup_tree,app_tree} about kino HOT 13 CLOSED

Sorry, the heir is from the table to the process. Everything else is perfect. :) Should we make the display of ETS tables opt-in or opt-out? Probably opt-in to avoid initial clutter?

from kino.

This looks nice!

Two questions:

1. how can both processes be associated to an ETS table? Usually we have one as owner? Is that the heir?
2. maybe the table should be inside the process box?

You can also try it out in a Registry to see how it looks, as it has two ETS tables.

from kino.

Thanks!

1. Correct. The solid line to the ETS table is the owning process and the dotted line is the heir process.
2. good idea....I didn't even think about that. Do you picture it using Mermaid subgraphs?

from kino.

Correct. The solid line to the ETS table is the owning process and the dotted line is the heir process.

I would invert the arrow then (perhaps annotate it with (heir) if possible.

good idea....I didn't even think about that. Do you picture it using Mermaid subgraphs?

That would be the idea but I am not sure if it is better in practice.

from kino.

Sounds good. I'll put together a couple hard coded mocks and post them here with which route we want to go.

from kino.

Here are some hardcoded Mermaid diagrams for how we can render this:

Diagram without subgraph:

Diagram with subgraph:

We can also drop the arrows all together for ETS tables and label both owner and heir to be explicit

Thoughts?

from kino.

I think the original one is less cluttered. I would only add an arrow to heir, but pointing to the process instead. What are your thoughts? Any thoughts @hugobarauna?

from kino.

When the direction of the ETS owner edge changes, Mermaid shuffles the graph in a not so intuitive way:

from kino.

I think the original one is less cluttered. I would only add an arrow to heir, but pointing to the process instead. What are your thoughts? Any thoughts @hugobarauna?

I think the original one is less cluttered.

Agree, without subgraphs.

I would only add an arrow to heir

From an educational point of view, maybe adding both "heir" and "owner" labels is a good direction.

For example, before that discussion, I didn't know an ETS table could have a relationship with two processes; I thought it was only related to one process. I just learned about the "heir" thing.

So, for someone like me (who is learning about ETS), if the diagram shows both labels, it can help me understand that an ETS table can have a relationship with two processes, one of which is the owner and the other the heir.

I'd keep both labels.

Regarding the arrows, the supervision diagram the way it is already has some implied semantics:

• an arrow from process A pointing to process B means that A supervises B
• a dotted line between two processes means they're linked (right? 🤔)

So, maybe we should use a different line from those two to imply a new semantic. Maybe just a simple line without arrows but with the "owner" or "heir" label.

from kino.

I would only add an arrow to heir

Sorry, I was not clear. What I meant to say is that I would add an arrow to heir in addition to the label. We should have arrows and labels in both. The reason I like the arrow in the heir case is because the "inheritance" happens by literally sending a message which transfers the table to the heir. But before the owner dies, nothing ever happens. The arrow in ownership is also important to say who owns who. For someone who is new, those relationships may not be clear, so I would emphasize them with arrows.

from kino.

I think I got it lol. Reread all the comments a couple times and I'm pretty sure this is what you are both looking for (I also added the table access inside the DB diagram):

from kino.

Sounds good. Pretty sure I have everything as discussed in PR #432

from kino.

Closing this as #432 was merged.

from kino.