There's also https://github.com/voormedia/rails-erd and my favorite https://github.com/amatsuda/erd which is fully interactive (can write migrations based on changes from the UI)

A word of caution: some of these rely on Graphviz, which is GPL’d. I stopped using my preferred ERD gem because of licensing issues.

Graphviz is licensed under the https://en.wikipedia.org/wiki/Eclipse_Public_License, not the GPL.

Neither library bundles or depends on Graphviz directly, you need to install Graphviz yourself. I'm wondering what kind of issues you're afraid of? Are you banned from using software that is licensed under a copyleft license somehow?

You’re correct. I think it’s ruby-graphviz that is (was?) under GPL.

Either way, as a lawyer, I wouldn’t let anything copyleft touch a project that is intended to be proprietary. If nothing else, the drafting of copyleft licenses is generally abominable, and prone to unintended consequences. For non-commercial projects, they’re fine but of marginal utility at best.

I recently discovered schemaspy and while it took a bit of working knowledge of java (need to execute a jar file from the command line) to get it working, it’s absolutely fantastic and one of the most sophisticated tools for dealing with ERDs at the DB level. Plus it’s open source! The only things I see that are possible improvements with this product are the fact that you don’t need to bootstrap a local database to generate this and it’s probably faster and easier to generate. I had a reasonably complex schema (200 ish tables with relationships) and schemaspy took about 3 minutes to generate the output. Once you do generate it though, it’s just a bunch of html and SVG in a folder so you don’t have to regenerate it until your scheme is updated.

I appreciate the side project but it's very hard to read. It doesnt really show much anything either. I much prefer https://github.com/voormedia/rails-erd

Example: https://camo.githubusercontent.com/f705fefa37f808758adbfa8e5...

Thanks! This diagram generated by rails-erd is indeed very nice. Something we should definitely look into to improve our visualization.

I think both tools serve slightly different purpose. How we're different is that we started by being a tool to help you draw databae diagrams by typing code. And adding Rails support was added rather quickly recently.

In a more general sense, I don't understand why we can't define field attributes in ONE spot and have most of the application software automatically just use that info rather than reinvent it in code?

Things were moving that way in the 80's it appeared, then OOP came along and overzealous practitioners declared RDBMS and tables as an official evil. Sure, different screens or reports may need different subsets of such fields, but filters can be built to sort or filter different "views" as needed per usage point. (OOP is good for some things, but not others.)

I'm tired of retyping or mass-replicating the field wheel. Let's return to table-oriented programming and data dictionaries. It's a D.R.Y. sin. Code is NOT the best place to store most field info. (RDBMS can also store navigation, screen, and menu info, but one thing at a time. 90% of typical CRUD could be done in a declarative sense.)

You are welcome to disagree; I encourage spirited debate.

Rails finds the fields from the dB and turns them into properties automatically... Isn't this exactly what you were asking?

Do you mean it generates code? That's still a "DRY" violation. And if you mean it only looks at the RDBMS table, then it has insufficient info. Describing a field well often requires more info/meta-data than what a typical RDBMS schema has.

Here's a list of typical attributes: db-field-name, type, display-name, form-sequence, list-sequence, relation-type (primary key, foreign key, etc.), reference-table, min-length, max-length, default-value, help-tip, bootstrap-column-width, grouping-filters/codes, search-form-type, and other optional do-dads.

It doesn't generate code, it "just" allows you to load and save fields by checking the tables structures. You still need to add code manually for relationships and some specific features.

Regarding the attributes you listed, looks to me like those are very CRUD-oriented. Many fields don't have a direct representation in the UI at all...

Example? One can pick and choose what fields are included in what using WHERE clause filters. And yes, not everything is necessarily displayed, but that won't "hurt" my suggestion.

It doesn't work. When I import my schema.rb file it takes issue with basically every line saying things like unexpected token etc. I'm using the "upload schema.rb" file button, but it's like it's trying to parse it as SQL.

Thanks! It seems like we haven't catered for more complex table syntax (when you added extra stuff like `force: delele` et al). We'll look into this and fix them.

Really appreciate your feedback here!

You also should show an error message when theres a problem with the schema. It says it doesnt understand "-1" as a default for an integer, which is obviously wrong. Firstly, thats a bug, but secondly it doesnt tell you when theres a problem with the file, it only shows a red X and doesnt even scroll there, so youre just left clicking the button 20 times because you think its broken.

How is the code parsed. Is it regex/string-reading based or is it executed?

It's string-reading, we use PegJS for that :) https://pegjs.org/

suggestion: actually run the schema.rb in a cloud function / lambda that has SQLite and ruby installed in it and then export the SQL via a db dump

This is really nice!

To those trying it out: if the diagram seems inaccurate, try dragging tables around.

I uploaded a very simple schema, but seemingly unrelated tables looked connected. Turns out it's 100% accurate, but relationships can run behind other tables and make it look like things are connected that aren't. Detangling is easy with a few drags/drops and you get a really nice diagram out of it.

This comment is precisely why I have a ton of respect for the people who develop visualization algorithms like in Graphviz. Given a DAG or ERD, the logic to properly render that as something that makes sense to your typical developer is HARD. Mad props to the people who tackle that problem.

Thanks for the love! Yes since rails convention is clear-cut and standardized, we can read those implicit conversions in the backend and convert to necessary relationships.

This is super useful, for Django you can use the Django-Extensions [1] to generate a similar, static representation.

[1] https://django-extensions.readthedocs.io/en/latest/graph_mod...

This looks really great and seems to handle some things better than rails-erd (multiple relationships between the same 2 models).

Are there any plans to make the interactive version exportable or embeddable? I'm working on an application right now that this UX would be perfect for.

Looks great. I used to use rails-erd when I needed a diagram. This seems a lot better

Looks neat! I was unable to use it on my more recent Rails projects which all have schema version that contain underscores. Example: `ActiveRecord::Schema.define(version: 2018_10_23_121007)`.

Thanks! Can you work around by changing that to a number and try again?

It is a number:

> 2018_10_23_121007.class => Fixnum

I've got an error, lambda functions inside schema aren't recognized; f.e.:

    t.datetime "created_at", default: -> { "now()" }

Thanks for this! Looks like we haven't handled all the custom syntax cases properly. Will sort it out shortly!

For now, a workaround is to remove those lambda and it should work!

This is really cool. Are there any examples on how to create svg like that or is this project open source somewhere?

Thanks! We actually built this in-house using D3js. Maybe we can look into open sourcing the rendering component.

works ok but I had to remove "on_delete: :cascade" on add_foreign_key lines.