Think about how we can express issue chains in the database

[sobolevn]

We have a nested structure of issues that are attached in two possible ways:

root issue:
  - issue1
  - issue2

Which means that these two issues are in parallel. And:

root issue:
  - issue1:
    - issue2

means that these two issues are blocked: issue2 is blocked until issue1 is resolved.

We can also have a situation when one issue is blocked by two other issues:

root issue:
  - issue1:
    - issue2:
      - issue3

We can only start to work on issue3 after both issue1 and issue2 are resolved.

It is important to understand that we can also have two or more blocks for just one issue:

root issue:
  - issue1
  - issue2
  - name: issue3
     after: [issue1, issue2]

It means that we can work on issue1 and issue2 on the same time. While issue3 can only be worked on after issue1 and issue2 are resolved.

In our django app we use:

class Issue(models.Model):
    after = models.ManyToManyField('self')

And https://django-treebeard.readthedocs.io/en/latest/ to make fast queries. We need something similar for Elixir.

Scope:

1. Research what tools are there for elixir
2. Write a short document like this one: https://github.com/wemake-services/kira/blob/master/docs/decisions/0001-http-client.md
3. Make a decision: which tools should we use

[YarNayar]

I'm looking at it, though since it's a research, I think it's better not to lock this issue to a single person and have a discussion instead, so if you interested please join and provide alternative design decisions.

[rsolovjov]

What if we use PostgresSQL ltree with EctoLtree or Hierarch?

• The ltree implements a materialized path, which very quick for INSERT/UPDATE/DELETE and pretty quick for SELECT operations
• It will be generally faster than using a recursive CTE or recursive function that constantly needs to recalculate the branching
• As built in query syntax and operators specifically designed for querying and navigating trees

Then

root issue:
  - issue1:
    - issue2:
      - issue3

can be represented as:

issue1 path: root_issue_id:issue1_id
issue2 path: root_issue_id:issue2_id:issue1_id
issue3 path: root_issue_id:issue3_id:issue2_id:ssue1_id

and

root issue:
  - issue1
  - issue2
  - name: issue3
     after: [issue1, issue2]

like

issue1 path: root_issue_id:issue1_id
issue2 path: root_issue_id:issue2_id
issue3 path: root_issue_id:issue3:id:issue2_id:ssue1_id

But I'm not completely sure that this is the right solution.

[sobolevn]

Just a quick note: we read and write a lot to this table.

@rsolovjov awesome! Looks promising.

[rsolovjov]

Ok. I'll do it