Ecto ERD - Entity-Relationship Diagram generator for Ecto

Your Libraries & OS Mentoring Libraries
, ,
1

Hi all!

I want to present a small library which provides a mix task for generating an Entity-Relationship Diagram for Ecto schemas.
You can check examples of output for a couple of open-source projects in docs or directly on GitHub.

Links:

36 Likes
2

Neat! Would be cool to be possible to generate input for https://dbdiagram.io.

5 Likes
3

Thank you for the suggestion, will add this to the roadmap :slight_smile:

1 Like
4

Added DBML support in version 0.2.0 :tada:

6 Likes
5

Added QuickDBD support in version 0.3.0

7 Likes
6

@fuelen thank you so much! I just used Ecto.ERD and it worked nicely.

2 Likes
7

Very cool. Thanks a lot.
It could probably replace ERAlchemy the tool I’m still using for this kind of documentation task.

2 Likes
8

Added PlantUML support in version 0.4.0 :partying_face:

5 Likes
9

Added Mermaid support in version 0.5.0 :partying_face:

7 Likes
10

Just used this for a take-home coding assessment where I’m asked to dissect an existing Ecto schema and fix some related tests.

This lib and the ERD it generated were extremely helpful. Thank you for building this!

3 Likes
11

Looks awesome. Going to test it soon. Thanks!

Edit: Just tried all formats and my favourite one is PlantUML as it’s generating best graph images.

I would like to suggest small changes:

  1. By default do not include migrations schema as it’s used only by ecto internally
  2. Can you change the id to something like: id : id (schema_name.table_name) (as passed to schema macro)?
  3. Can you also change other id fields to something like field_name : id (schema_name.table_name.foreign_key_field_name)
  4. Could you by default use last 2 parts of Elixir module, so we have just short MyContext.MySchema instead of MyApp.MyContext.MySchema?

So for example instead of:

MyApp.MyContext.MySchema
id : id
source_field_id : id
string_field : string

we would have:

MyContext.MySchema
id : id (public.my_table_name)
assoc_field : belongs to (public.my_another_table_name.source_field_id)
string_field : string
1 Like
12

Thank you for detailed feedback!

Sounds reasonable, but if there is an app that works with this table somehow, then we’d have to add more options to show the schema again. As for now, it can be easily removed using config file:

[
  map_node: fn
    %{source: "schema_migrations"} -> nil
    node -> node
  end
]

Primary keys are not required. Seems like you just want to see a table name. I think there are better ways of doing this, like add one more row which shows schema prefix and table name.

It is a bit noisy. The downside of PlantUML is that it doesn’t support precise connections between fields (using arrows), as it is done in our dot renderer.
What do you like in PlantUML the most? AFAIK, it uses Graphviz under the hood, and maybe we can modify/add an option to our dot renderer to have similar experience.

That’s a good idea to have an ability to format module name, but definitely not by default, as such names can overlap.

1 Like
13

I think working with that table is bad practice. First of all ecto rely on it, so developer should not:

  1. modify existing columns
  2. remove table
  3. add/modify/remove any rows

I don’t also see how other libraries are gonna using it and what’s more important is that schema_mirations is not documented anywhere in ecto and ecto_sql hex documentation (there is only schema_miration option in Repo callback). I would say that using schema_mirations table in any way is like using a private API.

Yeah, I completely forgot about that :sweat_smile: In that case it should be in new line under Module.Name.

In my personal opinion the diagram is the most clear. It’s not like that from very start I liked the arrows (maybe legend for them?) or colors, but I was used to it very quickly.

Yes, I also reminded that there could be for example .Schema suffix, so it’s better to make it easily configurable.

Ok, after modifications this is what I have in mind:

MyContext.MySchema
my_schema.my_table
id : id
assoc_field (assoc_field_id) : id (foreign_key_id)
string_field (legacy_string_field_source) : string
integer_field : int

If we could make DOT layout looks like PlantUML image then yes - with field connection it would be even more amazing and we do not need to note foreign_key_id then.

Generally I would like to use such graphs to show other people context about planned API (context + module) and database structure (source fields). This is why for example MyApp is completely not needed and so on …

1 Like